If include/generated/env.in does not exist, which is a typical case for
clean build, quiet_cmd_gen_envp command tries to delete this file
unconditionally.
This produces following warning during the build:
ENVP include/generated/env.in
rm: cannot remove 'include/generated/env.in': No such file or directory
Add '-f' option to the `rm` command to not complain if file does not
exist.
Fixes: f432eb6d8a ("env: Avoid using a leftover text-environment file")
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
colibri-imx6ull ethernet device is fec2, while the optional secondary
ethernet is fec1, update the ethernet aliases in the .dts file so that
ethaddr is set to fec2 and eth1addr to fec1.
Without this change the ethernet interfaces have a different
mac address between Linux and U-Boot.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Pull request for efi-2022-04-rc6
Documentation:
* Move VxWorks and Plan 9 to HTML documentation
* Move all command man-pages to a separate directory
Test:
* Fix pylint errors
UEFI
* Fix build flags for initrddump.efi
QEMU
* Remove unused function to get RNG device
If include/generated/environment.h exists (perhaps leftover from a build
of another board) it is used, even if the board currently being built does
not have a text environment.
This causes a build error. Fix it by emptying the file if it should not be
there.
Fixes: https://source.denx.de/u-boot/u-boot/-/issues/9
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Sean Anderson <seanga2@gmail.com>
Tested-by: Sean Anderson <seanga2@gmail.com>
It seems a copy'n'paste typo when tool had been introduced.
It has never had the 'exit' suffix in the file name. Hence,
the custom CFLAGS never been applied and, for example, BFD
linker complains:
LD lib/efi_loader/initrddump_efi.so
ld.bfd: lib/efi_loader/initrddump.o: warning: relocation in read-only section `.text.efi_main'
ld.bfd: warning: creating DT_TEXTREL in a shared object
Remove wrong 'exit' suffix from the custom CFLAGS variable.
Fixes: 65ab48d69d ("efi_selftest: provide initrddump test tool")
Fixes: 9c045a49a9 ("efi_loader: move dtbdump.c, initrddump.c to lib/efi_loader")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* Use f'' strings instead of .format().
* Correct sequence of imports.
* Remove a superfluous import.
* Add missing documentation.
* Replace yield by return.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This converts the existing README.plan9 to reST, and puts it under
the doc/usage/os directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At present the doc only mentions Arm, PowerPC and x86. RISC-V support
has been added since VxWorks SR0650 support for a while, and U-Boot
supports loading a RISC-V VxWorks kernel too. Let's document it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This converts the existing README.vxworks to reST, and puts it under
the doc/usage/os directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Currently all shell command docs are put in the doc/usage root.
Let's group them into cmd/ sub-directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Provide human readable descriptions of the speed nodes instead of the name
of constants from the code as it is already done for 'mmc rescan'
command in commit 212f078496 ("doc: mmc rescan speed mode").
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The QEMU platform has a function defined to get the random number
generator(RNG) device. However, the RNG device can be obtained simply
by searching for a device belonging to the RNG uclass. Remove the
superfluous platform function defined for the QEMU platform for
getting the RNG device.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Fixes for 2 gateworks platforms, Edison platform, incorrectly showing
2 logos on LCD screens, not cleaning a generated environment file and
correct the CONFIG_SYS_IMMR Kconfig migration on a number of MPC85xx
platforms.
The SPL does not update the memory node with the dram size from EEPROM
but instead we can use get_ram_size which does a simple memory test
to determine the available RAM. Update PHYS_SDRAM_SIZE to 4GiB as that
is the max used on the Venice boards.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
When migrating SYS_IMMR, I didn't allow for boards to provide
non-default values here. This lead to an incorrect migration on the
platforms where CONFIG_SYS_IMMR is set to CONFIG_SYS_CCSRBAR and
CONFIG_SYS_CSSRBAR is NOT the same as CONFIG_SYS_CCSRBAR_DEFAULT. Add
text to the prompt so that non-default values can be used and re-migrate
the platforms that have CONFIG_SYS_IMMR=CONFIG_SYS_CSSRBAR where
CONFIG_SYS_CSSRBAR != CONFIG_SYS_CCSRBAR_DEFAULT.
Fixes: be7dbb60c5 ("Convert CONFIG_SYS_IMMR to Kconfig")
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Pali Rohár <pali@kernel.org>
'make sifive_unamtched_defconfig; make clean; make' fails if file
include/generated/env.in exists. 'make clean' should remove all files that
stop building.
Add file include/generated/env.in to the clean target.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Currently, on imx6sabresd and gwventana boards, the company logo
and U-Boot logo are shown.
The correct behavior is to show only the company logo, if available,
and not both logos.
Reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Tested-by: Tim Harvey <tharvey@gateworks.com> #gw_ventana
commit 7c84319af9c7 ("dm: gpio: Correct use of -ENODEV in drivers")
changed the return code for an I2C NAK from -ENODEV to -EREMOTEIO.
Update the gsc_i2c_read and gsc_i2c_write functions for this change
to properly retry the transaction on a NAK meaning the GSC is busy.
Fixes: 7c84319af9 ("dm: gpio: Correct use of -ENODEV in drivers")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Enable ONFI detection to fix NAND chip configuration. Without this
the NAND oobsize will be wrong which leads to invalid ECC strength and
incompatibility with the previous configuration.
Fixes: 777f333c37 ("imx: ventana: enable dm for MTD and NAND")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Previous u-boot code changed the default bch setting behavior and caused
backward compatible issue. This fix choose the legacy bch geometry back
again as the default option. If the minimum ecc strength that NAND chips
required need to be chosen, it can be enabled by either adding DT flag
"fsl,use-minimum-ecc" or CONFIG_NAND_MXS_USE_MINIMUM_ECC in configs. The
unused flag "fsl,legacy-bch-geometry" get removed.
Fixes: 51cdf83eea (mtd: gpmi: provide the option to use legacy bch geometry)
Fixes: 616f03daba (mtd: gpmi: change the BCH layout setting for large oob NAND)
Tested-by: Tim Harvey <tharvey@gateworks.com>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Han Xu <han.xu@nxp.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
The code was mistakenly initializing the input buffer twice.
Tested to be working on BeagleBone by adjusting CONFIG_SYS_BOOTM_LEN to
64MiB (probably works with less) and preparing uImage with:
cat arch/arm/boot/Image \
| zstd --ultra -22 --zstd=windowLog=22 \
> linux.bin.zst
mkimage -A arm -T kernel uImage -C zstd -d linux.bin.zst \
-a 0x80008000 -e 0x80008000
Without the windowLog restriction, bootm fails with a zstd decompression
error 7 (window too large), which I haven't troubleshooted.
There should be a bit more documentation on the feature...
Reviewed-by: Simon Glass <sjg@chromium.org>
Fixes: 458b30af66 image: Update image_decomp() to avoid ifdefs
make sandbox_defconfig
make mrproper
make tests
fails with
../drivers/video/u_boot_logo.S: Assembler messages:
../drivers/video/u_boot_logo.S:5: Error: file not found: drivers/video/u_boot_logo.bmp
We have to delete the generated file.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current approach for setting the environment variables that
describe the memory layout runs the risk of overlapping with
reserved memory regions. Use the lmb code to derive the addresses
for these variables instead.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The firmware on larger NVMe drives needs more than 100ms to come up.
Change the timeout to 1s.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Provide a unit test for
* efidebug boot add
* efidebug boot order
* bootefi bootmgr
* initrd via EFI_LOAD_FILE2_PROTOCOL
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Up to now the initrddump.efi application has drained the input after
showing the prompt. This works for humans but leads to problems when
automating testing. If the input is drained, this should be done before
showing the prompt.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
initrddump.efi uses colored output and clear the screen. This is not
helpful for integration into Python tests. Allow specifying 'nocolor' in
the load option data to suppress color output and clearing the screen.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Commit f11513d997 ("net: phy: realtek: Add tx/rx delay config for
8211e") made the Realtek PHY driver honour the phy-mode DT property,
to set up the proper delay scheme for the RX and TX lines. A similar
change in the kernel revealed that those properties were mostly wrong.
The kernel DTs got updated over the last few months, but we were missing
out on the U-Boot version.
Just sync in the phy-mode properties from the mainline kernel,
v5.17-rc7, to avoid the breaking DT sync that late in the cycle.
This fixes Ethernet operation on the affected boards.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Commit 5bc4cd05d7 ("sunxi: move non-essential code out of s_init()")
moved the call to eth_init_board() from s_init() into board_init_f().
This means it's now only called from the SPL, which makes sense for
most of the other moved low-level functions. However the GMAC pinmux and
clock setup in eth_init_board() was not happy about that, so it broke
the sun7i GMAC.
Since Ethernet is of no use in the SPL anyway, just move the call into
board_init(), which is only run in U-Boot proper.
This fixes Ethernet operation for the A20 SoCs, which broke in
v2022.04-rc1, with the above mentioned commit.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Petr Štetiar <ynezz@true.cz> [a20-olinuxino-lime2]
Commit 0934dddc64 ("arm: a37xx: Update DTS files to version from
upstream Linux kernel") ported Linux's device-tree files for Armada 3720
SOCs. This broke SPI support on some Espressobin boards and results in
following U-Boot error:
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: f7, 30, 0b
*** Warning - spi_flash_probe_bus_cs() failed, using default environment
Before that commit DT node for SPI was called 'spi-flash@0' and after
that commit it is called 'flash@0'. Before that commit 'spi-max-frequency'
was set to 50000000 and after it is 104000000.
Rename DT node 'spi-flash@0 in armada-3720-espressobin-u-boot.dtsi to
'flash@0' and set custom U-Boot 'spi-max-frequency' back to 50000000.
With this change SPI is working on Espressobin again and it is detected
with JEDEC ids ef, 60, 16 on our tested unit.
Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Note that it is unknown why spi-max-frequency with value 104000000 does not
work in U-Boot as it works fine with Linux kernel. Also note that in
defconfig file configs/mvebu_espressobin-88f3720_defconfig is set option
CONFIG_SF_DEFAULT_SPEED=40000000 which is different value than in DT.
Fixes: 0934dddc64 ("arm: a37xx: Update DTS files to version from upstream Linux kernel")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
i2c changes for fixes-for-2022.04
- atsha204a-i2c.c
DTS and I2C fixes for Atmel ATSHA204 from Adrian
- i2c: fix always-true condition in i2c_probe_chip()
from Nikita
- eeprom: Do not rewrite EEPROM I2C bus with DM I2C enabled
from Marek
- clarify bootcount documentation fix from Michael
Commit 0934dddc64 ("arm: a37xx: Update DTS files to version from
upstream Linux kernel") ported Linux's device-tree files for Armada 3720
SOCs. This broke USB port on Turris MOX, because in Linux' DTS the bus
voltage supply is described as a `phy-supply` property of connector
node, a mechanism that is not supported in U-Boot yet.
For now, fix this by adding `vbus-supply` to usb3 node.
Fixes: 0934dddc64 ("arm: a37xx: Update DTS files to version from upstream Linux kernel")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
With DM I2C, the EEPROM bus has been correctly configured in
eeprom_execute_command() already. Do not reconfigure it here
with hard-coded bus number again.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
This patch replaces use fdtdec_get_addr with simpler dev_read_addr().
fdtdec_get_addr doesn't work properly on ZynqMP-based (64bit) system. Although
not confirmed, it could be related to the fact, that quoting the documentation,
"This variant hard-codes the number of cells used to represent the address and
size based on sizeof(fdt_addr_t) and sizeof(fdt_size_t)".
Signed-off-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Once request is sent, and before receiving a response, the delay is required.
This patch fixes missing delay for before first response try.
Signed-off-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Pull request for efi-2022-04-rc5
Documentation:
* Fix documentation of FIP creation for Amlogic boards
* Update Nokia RX-51 QEMU documentation
* Add Raspberry Pi documentation
UEFI:
* Fix booting via short form device paths
* Support short form device paths in 'efidebug boot add'
* Fix ESP detection for capsule updates
* Allow ACPI table usage even if device-tree exists - ignore DT
* OP-TEE based GetVariable(): return attributes when buffer too small
The tools dtbdump.efi and initrddump.efi are useful for Python testing even
if CONFIG_EFI_SELFTEST=n.
Don't clear the screen as it is incompatible with Python testing.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The block IO protocol may be installed on any handle. We should make
no assumption about the structure the handle points to.
efi_disk_is_system_part() makes an illegal widening cast from a handle
to a struct efi_disk_obj. Remove the function.
Fixes: Fixes: 41fd506842 ("efi_loader: disk: add efi_disk_is_system_part()")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The GUID of partitions is sufficient for identification and will stay
constant in the lifetime of a boot option. The preceding path of the
device-path may change due to changes in the enumeration of devices.
Therefore it is preferable to use the short-form of device-paths in load
options. Adjust the 'efidebug boot add' command accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The boot manager must support loading from boot options using a short-form
device-path, e.g. one where the first element is a hard drive media path.
See '3.1.2 Load Options Processing' in UEFI specification version 2.9.
Fixes: 0e074d1239 ("efi_loader: carve out efi_load_image_from_file()")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Let function efi_dp_find_obj() additionally check if a given protocol is
installed on the handle relating to the device-path.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_dp_find_obj() should not return any handle with a partially matching
device path but the handle with the maximum matching device path.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.
To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
It add documentation on licencing & provides links to the amlogic-boot-fip
pre-built files collections.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Fix documentation path in deprecated warning message about device
driver.
Signed-off-by: Johannes Krottmayer <krjdev@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fix documentation path in warning message about deprecated device driver.
Signed-off-by: Johannes Krottmayer <krjdev@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
A comma at the end of a line gives sometimes strange
effects in combination with some code formatters,
so replace a comma by a semicolon in the sdram_rk3188.c
and sdram_rk3288.c files.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
U-Boot can be chainloaded from vendor firmware on ARM64 chromebooks from
a GPT partition (roughly the same as in doc/chromium/chainload.rst), but
an appropriate image header must be built-in to the U-Boot binary by
enabling LINUX_KERNEL_IMAGE_HEADER.
This header has a field for an image load offset from 2MiB alignment
which must also be customized through LNX_KRNL_IMG_TEXT_OFFSET_BASE.
Set it equal to SYS_TEXT_BASE by default for Rockchip boards, which
happens to make this offset zero and works fine on chromebook_kevin
both for chainloading and bare-metal use.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Remove double semi-colon that has been forgotten while adding the
driver. This is only a style fix since it doesn't change the
functionality of the driver.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This is very useful to access the LibreComputer eMMC as removable
storage from a PC (e.g. like so `ums 0 mmc 0`). It has been tested as
working on my Renegade board.
Signed-off-by: Leonidas P. Papadakos <papadakospan at gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The current files and directories with wildcard patterns for
Rockchip patches in MAINTAINERS is not always complete.
Add the regex for DT related files and a generic regex for
catching some other forgotten cases, so that the maintainers
receive all Rockchip related patches.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Add support for Kevin, an RK3399-based convertible chromebook that is
very similar to Bob. This patch is mostly based on existing support for
Bob, with only minor changes for Kevin-specific things.
Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV,
so adjust it here in the dts as well. The rk3399-gru-kevin devicetree
has an unknown event code reference which has to be defined, set it
to the Linux counterpart. The new defconfig is copied from Bob with the
diffconfig:
DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin"
DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" -> "rockchip/rk3399-gru-kevin.dtb"
VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400
VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600
+TARGET_CHROMEBOOK_KEVIN y
With this Kevin can boot from SPI flash to a usable U-Boot prompt on the
display with the keyboard working, but cannot boot into Linux for
unknown reasons.
eMMC starts in a working state but fails to re-init, microSD card works
but at a lower-than-expected speed, USB works but causes a hang on
de-init. There are known workarounds to solve eMMC and USB issues.
Cc: Marty E. Plummer <hanetzer@startmail.com>
Cc: Simon Glass <sjg@chromium.org>
[Alper: commit message, resync config with Bob, update MAINTAINERS,
add to Rockchip doc, add Kconfig help message, set regulator]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
This patch enables some configs that should be working on the Bob board,
based on what is observed to work on the Kevin board.
The Bob board uses an Embedded DisplayPort panel compatible with the
simple panel and Rockchip eDP drivers. Its backlight is controlled by
the Chromium OS Embedded Controller Pulse Width Modulator. Enable these
for the board.
Also set VIDEO_ROCKCHIP_MAX_{XRES,YRES} to 1280x800, the resolution of
its panel. This had to be done for the Kevin board, but it's untested if
this is actually necessary for Bob.
The Rockchip video driver needs to assert/deassert some resets, so also
enable the reset controller. RESET_ROCKCHIP defaults to y for this board
when DM_RESET=y, so it's enough to set that.
The Bob board has two USB 3.0 Type-C ports and one USB 2.0 Type-A port
on its right side. Enable the configs relevant to USB devices so these
can be used. This is despite a known issue with RK3399 boards where USB
de-init causes a hang, as there is a known workaround.
Some other rk3399-based devices enable support for the SoC's random
number generator in commit a475bef534 ("configs: rk3399: enable rng on
firefly/rock960/rockpro64"), as it can provide a KASLR seed when booting
using UEFI. Enable it for Bob as well.
The default misc_init_r() for Rockchip boards sets cpuid and ethernet
MAC address based on e-fuse block. A previous patch extends this on Gru
boards to set registers related to SoC IO domains as is necessary on
these boards. Enable this function and configs for it on Bob.
The microSD card slot on this board (and others based on Gru) is
connected to a GPIO controlled regulator (ppvar-sd-card-io), which must
be operable by U-Boot. Enable the relevant config option to allow this.
Bob boards also use the Winbond W25Q64DW SPI flash chip, enable support
for Winbond SPI flash chips in the board config so U-Boot can boot with
this chip.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
This adds some devicetree settings for the Gru-based boards, based on
what works on a Kevin board.
Gru-based boards usually have an 8MiB SPI flash chip and boot from it.
Make the u-boot.rom file intended to be flashed on it match its size.
Add properties for booting from SPI, and only try to boot from SPI as
MMC and SD card don't seem to work in SPL yet.
The Chromium OS EC needs a delay between transactions so it can get
itself ready. Also it currently uses a non-standard way of specifying
the interrupt. Add these so that the EC works reliably.
The Rockchip Embedded DisplayPort driver is looking for a rockchip,panel
property to find the panel it should work on. Add the property for the
Gru-based boards.
The U-Boot GPIO controlled regulator driver only considers the
"enable-gpios" devicetree property, not the singular "enable-gpio" one.
Some devicetree source files have the singular form as they were added
to Linux kernel when it used that form, and imported to U-Boot as is.
Fix one instance of this in the Gru boards' devicetree to the form that
works in U-Boot.
The PWM controlled regulator driver complains that there is no init
voltage set for a regulator it drives, though it's not clear which one.
Set them all to the voltage levels coreboot sets them: 900 mV.
The RK3399 SoC needs to know the voltage level that some supplies
provides, including one fixed 1.8V audio-related regulator. Although
this synchronization is currently statically done in the board init
functions, a not-so-hypothetical driver that does this dynamically would
query the regulator only to get -ENODATA and be confused. Make sure
U-Boot knows this supply is at 1.8V by setting its limits to that.
Most of this is a reapplication of commit 08c85b57a5 ("rockchip: gru:
Add extra device-tree settings") whose changes were removed during a
sync with Linux at commit 167efc2c7a ("arm64: dts: rk3399: Sync
v5.7-rc1 from Linux"). Apply things to rk3399-gru-u-boot.dtsi instead so
they don't get lost again.
Signed-off-by: Simon Glass <sjg@chromium.org>
[Alper: move to -u-boot.dtsi, rewrite commit message, add more nodes]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
The RK3399 SoC needs to know the voltage value provided by some
regulators, which is done by setting relevant register bits. Configure
these the way other RK3399 boards do, but with the same values as are
set in the equivalent code in coreboot.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
On RK3568, a register bit must be set to enable Enhanced Strobe.
However, it appears that the address of this register may differ from
vendor to vendor and should be read from the underlying MMC IP. Let the
Rockchip SDHCI driver read this address and set the relevant bit when
Enhanced Strobe configuration is requested.
The IP uses a custom mode select value (0x7) for HS400, use that instead
of the common but non-standard SDHCI_CTRL_HS400 value (0x5). Also add
some necessary DLL_STRBIN and DLL_TXCLK configuration for HS400.
Additionally, a bit signifying that the connected hardware is an eMMC
chip must be set to enable Data Strobe for HS400 and HS400ES modes. Also
make the driver set this bit as appropriate.
This is partly ported from Linux's Synopsys DWC MSHC driver which
happens to be the underlying IP. (drivers/mmc/host/sdhci-of-dwcmshc.c in
Linux tree).
Co-developed-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
On RK3399, a register bit must be set to enable Enhanced Strobe.
Let the Rockchip SDHCI driver set it when Enhanced Strobe configuration
is requested. However, having it set makes the lower-speed modes stop
working and makes reinitialization fail, so let it be unset as needed in
set_control_reg().
This is mostly ported from Linux's Arasan SDHCI driver which happens
to be the underlying IP. (drivers/mmc/host/sdhci-of-arasan.c in Linux
tree).
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Delegate setting the Enhanced Strobe configuration to individual drivers
if they set a function for it. Return -ENOTSUPP if they do not, like
what the MMC uclass does.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Generic SDHCI driver received support for checking the busy status by
polling the DAT[0] level instead of waiting for the worst MMC switch time.
Unfortunately, it appears that this does not work for Xenon controllers
despite being a part of the standard SDHCI registers and the Armada 3720
datasheet itself telling that BIT(20) is useful for detecting the DAT[0]
busy signal.
I have tried increasing the timeout value, but I have newer managed to
catch DAT_LEVEL bits change from 0 at all.
This issue appears to hit most if not all SoC-s supported by Xenon driver,
at least A3720, A8040 and CN9130 have non working eMMC currently.
So, until a better solution is found drop the wait_dat0 OP for Xenon.
I was able to only test it on A3720, but it should work for others as well.
Fixes: 40e6f52454 ("drivers: mmc: Add wait_dat0 support for sdhci driver")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Stefan Roese <sr@denx.de>
e-MMC and SD standards differ for some CID fields:
- 6 Byte Name - assigned by Manufacturer (SD 5 Byte)
- 1 Byte OEM - assigned by Jedec (SD 2 Byte)
See e-MMC standard (JEDEC Standard No. 84-B51), 7.2.3 (OID) and 7.2.4 (PNM)
Signed-off-by: Max Merchel <Max.Merchel@tq-group.com>
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
After commit f132aab403 ("Revert "mmc: fsl_esdhc_imx: use
VENDORSPEC_FRC_SDCLK_ON to control card clock output""), it
involve issue in mmc_switch_voltage(), because of the special
design of usdhc.
For FSL_USDHC, it do not implement VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
these are reserved bits(Though RM contain the definition of these bits,
but actually internal IC logic do not implement, already confirm with
IC team). Instead, use VENDORSPEC_FRC_SDCLK_ON to gate on/off the card
clock output. Here is the definition of this bit in RM:
[8] FRC_SDCLK_ON
Force CLK output active
Do not set this bit to 1 unless it is necessary. Also, make sure that
this bit is cleared when uSDHC’s clock is about to be changed (frequency
change, clock source change, or delay chain tuning).
0b - CLK active or inactive is fully controlled by the hardware.
1b - Force CLK active
In default, the FRC_SDCLK_ON is 0. This means, when there is no command
or data transfer on bus, hardware will gate off the card clock. But in
some case, we need the card clock keep on. Take IO voltage 1.8v switch
as example, after IO voltage change to 1.8v, spec require gate off the
card clock for 5ms, and gate on the clock back, once detect the card
clock on, then the card will draw the dat0 to high immediately. If there
is not clock gate off/on behavior, some card will keep the dat0 to low
level. This is the reason we fail in mmc_switch_voltage().
To fix this issue, and concern that this is only the fsl usdhc hardware
design limitation, set the bit FRC_SDCLK_ON in the beginning of the
wait_dat0() and clear it in the end. To make sure the 1.8v IO voltage
switch process align with SD specification.
For standard tuning process, usdhc specification also require the card
clock keep on, so also add these behavior in fsl_esdhc_execute_tuning().
Reviewed-by: Marek Vasut <marex@denx.de>
Tested-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Commit 0934dddc64 ("arm: a37xx: Update DTS files to version from
upstream Linux kernel") ported Linux's device-tree files for Armada 3720
SOCs. This broke network on Turris MOX, because the SOC's MDIO bus in
U-Boot currently isn't probed via DM as it's own device, but is
registered as part of mvneta's driver, which means that pinctrl
definitions are not parsed for the MDIO bus node. Also mvneta driver
does not consider "phy-handle" property, only "phy".
For now, fix this by adding armada-3720-turris-mox-u-boot.dtsi file
returning the MDIO to how it was defined previously.
A better solution (using proper mvmdio DM driver) is being work on, but
will need testing on various boards, and we need the bug fixed now for
the upcoming release.
Fixes: 0934dddc64 ("arm: a37xx: Update DTS files to version from upstream Linux kernel")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
mtd: add NAND write protect support to stm32_fmc2_nand
stm32mp1 bsec: Add permanent lock write support
stm32mp1 bsec: Add dev in function description
cmd_stboard: Update test on misc_read() result
video: fix the check of return value of clk_set_rate in stm32_ltdc
DT: Alignment with kernel v5.17 for stm32mp15
DT: Add USB OTG pinctrl and regulator in SPL for DHCOR
DT: Move vdd_io extras into Avenger96 extras
DT: Add DFU support for DHCOM recovery
ram: stm32mp1: Unconditionally enable ASR
psci: Implement PSCI system suspend and DRAM SSR for stm32mp
The designware spi driver unconditionally uses polling.
The comment to spi_hw_init() also states that the function should disable
interrupts.
According to the DesignWare DW_apb_ssi Databook, value 0xff in IMR enables
all interrupts. Since we want to mask all interrupts write 0x0 instead.
On the canaan k210 board, pressing the reset button twice to reset the
board will run u-boot. If u-boot boots Linux without having SPI interrupts
masked, Linux will hang as soon as interrupts are enabled, because of an
interrupt storm.
Properly masking the SPI interrupts in u-boot allows us to successfully
boot Linux, even after resetting the board.
Fixes: 5bef6fd79f ("spi: Add designware master SPI DM driver used on SoCFPGA")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
[Niklas: rewrite commit message]
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
The Canaan Kendryte K210 SoC DW apb_ssi v4 spi controller is documented
to have a 32 word deep TX and RX FIFO, which spi_hw_init() detects.
However, when the RX FIFO is filled up to 32 entries (RXFLR = 32), an
RX FIFO overrun error occurs. Avoid this problem by force setting
fifo_len to 31.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Linux kernel fpioa pinctrl driver expects the sysctl phandle and the
power bit offset of the fpioa device to be specified as a single
property "canaan,k210-sysctl-power".
Replace the "canaan,k210-sysctl" and "canaan,k210-power-offset"
properties with "canaan,k210-sysctl-power" to satisfy the Linux kernel
requirements. This new property is parsed using the existing function
dev_read_phandle_with_args().
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Linux drivers for many of the K210 peripherals depend on the power bus
clock to be specified. Add the missing clocks and their names to avoid
problems when booting Linux using u-boot DT.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
"kendryte" is the marketing name for the K210 RISC-V SoC produced by
Canaan Inc. Rather than "kendryte,k210", use the usual "canaan,k210"
vendor,SoC compatibility string format in the device tree files and
use the SoC name for file names.
With these changes, the device tree files are more in sync with the
Linux kernel DTS and drivers, making uboot device tree usable by the
kernel.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This patch configures U-Boot SPL for DHCOM SoM to permit DFU upload of
SPL and subsequent u-boot.itb for recovery or commissioning purposes.
The DFU usage procedure is identical to STM32MP1 DHCOR SoM, see commit
3919aa1722 ("ARM: dts: stm32: Add DFU support for DHCOR recovery") ,
except for switching the SoM into DFU mode. By default, the DHCOM SoM
has no dedicated mechanism for setting BOOTn straps into UART/USB mode,
therefore to enter DFU mode, the SoC must fail to boot from boot media
which can be selected by the BOOTn strap override mechanism first and
then fall back to DFU mode.
In case of a SoM with pre-populated BOOTn strap override button, power
the system off, remove microSD card (if applicable), hold down the BOOTn
strap override button located between eMMC and SoM edge connector, power
on the SoM. The SoC will fail to boot from SD card and fall back into
DFU mode.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Fix the following warning in SPL and make sure that even DTs which
enforce Vbus detection using u-boot,force-vbus-detection;, the DFU
in SPL will work.
dwc2-udc-otg usb-otg@49000000: prop pinctrl-0 index 0 invalid phandle
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Device tree alignment with Linux kernel v5.17-rc1
- ARM: dts: stm32: add pull-up to USART3 and UART7 RX pins
on STM32MP15 DKx boards
- ARM: dts: stm32: clean uart4_idle_pins_a node for stm32mp15
- ARM: dts: stm32: tune the HS USB PHYs on stm32mp15xx-dkx
- ARM: dts: stm32: tune the HS USB PHYs on stm32mp157c-ev1
- ARM: dts: stm32: fix stusb1600 pinctrl used on stm32mp157c-dk
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The clk_set_rate() function returns rate as an 'ulong' not
an 'int' and rate > 0 by default.
This patch avoids to display the associated warning when
the set rate function returns the new frequency.
Fixes: aeaf330649 ("video: stm32: stm32_ltdc: add bridge to display controller")
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Update management of misc_read/misc_write, which now returns length of
data after the commit 8729b1ae2c ("misc: Update read() and write()
methods to return bytes xfered"): raise a error when the result is not
the expected length.
Fixes: 658fde8a36 ("board: stm32mp1: stboard: lock the OTP after programming")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add support of the permanent lock support in U-Boot proper
when BSEC is not managed by secure monitor (TF-A SP_MIN or OP-TEE).
This patch avoid issue with stm32key command and fuse command
on basic boot for this missing feature of U-Boot BSEC driver.
Reported-by: Johann Neuhauser <jneuhauser@dh-electronics.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tested-by: Johann Neuhauser <jneuhauser@dh-electronics.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
This patch adds the support of the WP# signal. WP will be disabled
before the first access to the NAND flash.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
This saves about 12 kBytes image size and helps to stay within the
size limit.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Soeren Moch <smoch@web.de>
Commit 90f262a695 ("vexpress64: Clean up BASE_FVP boot configuration")
cleaned up the usage of default address variables, but missed to update
the address for the kernel in the FVP's bootcmd definition.
Change ${kernel_addr} to read ${kernel_addr_r} to bring back the
automated boot for the fastmodel.
Also use "setenv" instead of the potentially ambiguous "set" on the way.
Fixes: 90f262a695 ("vexpress64: Clean up BASE_FVP boot configuration")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Initialization and power on operations of links have been moved under the
link device in the Sierra SerDes driver. Also, the UCLASS of
sierra_phy_provider has been changed to UCLASS_MISC.
Therefore, fix the probing of SerDes0 instance accordingly.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Georgi Vlaev <g-vlaev@ti.com>
In commit 6f46c7441a ("phy: cadence: Sierra: Add a UCLASS_PHY device for
links"), a separate udevice of type UCLASS_PHY was created for each link.
Therefore, move the corresponding link operations under the link device.
Also, change the uclass of sierra phy to UCLASS_MISC as it is no longer the
phy device.
Fixes: 6f46c7441a ("phy: cadence: Sierra: Add a UCLASS_PHY device for links")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Georgi Vlaev <g-vlaev@ti.com>
The Rockchip RK3399 eMMC PHY has to be power-cycled while changing its
clock speed to some higher speeds. This is dependent on the desired
SDHCI clock speed, and it looks like the PHY should be powered off while
setting the SDHCI clock in these cases.
Commit ac804143cf ("mmc: rockchip_sdhci: add phy and clock config for
rk3399") attempts to do this in the set_ios_post() hook by setting the
SDHCI clock once more while the PHY is turned off/on as necessary, as
the SDHCI framework does not provide a way to override how it sets its
clock. However, the commit breaks reinitializing the eMMC on a few
boards including chromebook_kevin and reportedly ROCKPro64.
This patch reworks the power cycling to utilize the SDHCI framework
slightly better (using the set_control_reg() hook to power off the PHY
and set_ios_post() hook to power it back on) which happens to fix the
issue, at least on a chromebook_kevin.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Remap PCI I/O space to the bus address 0x0 in the Armada 37xx device-tree
in order to support legacy I/O port based cards which have hardcoded I/O
ports in low address space.
Some legacy PCI I/O based cards do not support 32-bit I/O addressing.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Commit 9e6d71d2b5 ("tools: kwboot: Allow to use -b without image path as
the last getopt() option") broke usage of kwboot with following arguments:
kwboot -t -B 115200 /dev/ttyUSB0 -b u-boot-spl.kwb
Fix parsing of option -b with optional argument again.
Fixes: 9e6d71d2b5 ("tools: kwboot: Allow to use -b without image path as the last getopt() option")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reported-by: Tony Dinh <mibodhi@gmail.com>
Tested-by: Tony Dinh <mibodhi at gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Call kwboot_open_tty() which baudrate value which was specified at the
command line by option -B. This function returns error if baudrate is not
supported by selected tty device.
Initial baudrate for image transfer is always 115200, so call
kwboot_tty_change_baudrate() with value 115200 immediately after
kwboot_open_tty() if baudrate specified by option -B is different than
115200.
This makes kwboot fail immediately, informing that baudrate is unsupported,
instead of failing only after the first part of image is already sent.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Custom baudrate different than 115200 may be specified only when kwboot is
not going to send boot/debug message pattern or when it is going to send
boot message pattern with image file (in which case baudrate change happens
after sending kwbimage header). BootROM detects boot/debug message pattern
only at baudrate 115200.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
dev_read_size() returns -EINVAL (-22) if the property "g-tx-fifo-size"
does not exist. If that's the case, we now keep the default value of 0.
Signed-off-by: Wolfgang Grandegger <wg@aries-embedded.de>
This enum is currently anonymous. Add a name so it can be used in the
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Pull request for efi-2022-04-rc3-2
Documentation:
* Fix description for SiFive Unmatched
* Add libgnutls28-dev to build dependencies
UEFI
* Avoid possibly invalid GUID pointers for protocol interfaces
Other
* Serial console support for cls command
InstallProtocolInterface() is called with a pointer to the protocol GUID.
There is not guarantee that the memory used by the caller for the protocol
GUID stays allocated. To play it safe the GUID should be copied to U-Boot's
internal structures.
Reported-by: Joerie de Gram <j.de.gram@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently the cls command does not support the serial console
The screen can be cleared in the video uclass, the colored frame buffer
console, and the serial console by sending the same escape sequence.
This reduces the cls command to a single printf() statement on most
boards.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some sunxi boards ship with SPI flash, which allows booting through the
BootROM. We cover this functionality by a separate SPL "mini" driver.
Separately we have a proper DM_SPI driver for U-Boot proper, which
provides access to the SPI flash through the "sf" command. That allows
to update the firmware on the SPI flash, also to store the environment
there.
However only very few boards actually enable support for U-Boot proper,
even though that would work and the SPL part is configured.
Use the cleaned up configuration scheme to enable SPI flash on those
boards which mention a SPI flash in their .dts, or which use the SPL SPI
support.
Out of the box this would enable storing the environment on the SPI
flash, and allows people to read or write the flash from U-Boot, for
instance to update the SPI flash when booted via an SD card.
For this to actually work there must be a "spi0" alias in the DT, which
most boards are missing. But this should be addressed separately.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Now that sunxi uses CONFIG_SPI more sanely, and can also now properly
load the environment from SPI flash, let's enable the symbol that
actually considers the SPI flash when accessing the environment.
As this symbol depends on CONFIG_SPI, which we now only enable if the
board has a SPI flash, we can make if "default y" for all Allwinner
boards.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Currently we only support to load the environment from raw MMC or FAT
locations on Allwinner boards. With the advent of SPI flash we probably
also want to support using the environment there, so we need to become
a bit more flexible.
Change the environment priority function to take the boot source into
account. When booted from eMMC or SD card, we use FAT or MMC, if
configured, as before.
If we are booted from SPI flash, we try to use the environment from
there, if possible. The same is true for NAND flash booting, although
this is somewhat theoretical right now (as untested).
This way we can use the same image for SD and SPI flash booting, which
allows us to simply copy a booted image from SD card to the SPI flash,
for instance.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
To allow loading and storing the environment from SPI flash, adjust the
raw offset variables for Allwinner boards to make sense there.
U-Boot (including SPL and other blobs) is loaded from the beginning of
SPI flash, so move the environment location as far back as possible, to
not create unnecessary limits. As those offsets are shared with (now
mostly unused) raw MMC environment, we should respect the common one
megabyte limit, which also makes sense on SPI flash.
So limit the environment for those raw locations to 64KB, and place it
just below 1MB (@960KB).
Those values are currently unused, unless someone forcibly enables the
raw MMC environment. In this case it would break as of now, as the
current offset of 544KB is far too low for the current (arm64) U-Boot
proper.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Commit 7945caf22c ("arm: sunxi: Enable SPI/SPI-FLASH support for A64")
selected CONFIG_SPI by default on all Allwinner A64 boards, even though
only 4 out of the 14 A64 boards have a SPI flash chip. All other SoCs
had to manually select DM_SPI and friends, even though they are a
platform property (the sunxi SPI driver is DM_SPI only).
Clean this up to allow easy selection of SPI flash support in U-Boot
proper, by selecting DM_SPI and DM_SPI_FLASH *if* CONFIG_SPI is
selected, for *all* Allwinner SoCs. This simplifies the defconfig for
two Libretech boards already.
Also remove the forced CONFIG_SPI from the A64 Kconfig, instead let the
four boards which allow SPI booting select this explicitly.
Any board wishing to support SPI flash in U-Boot proper now just defines
CONFIG_SPI and CONFIG_SPI_FLASH_<vendor> in its defconfig, Kconfig takes
care of the rest.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Mechanically convert video_hw_init() function to UCLASS_VIDEO probe
callback and replace CONFIG_CFB_CONSOLE by CONFIG_DM_VIDEO.
As framebuffer base address is setup by the bootloader which loads U-Boot,
set plat->base to that fixed framebuffer address.
This change was tested in qemu n900 machine and is working fine.
What does not work is CONFIG_VIDEO_LOGO, seems to be buggy.
Signed-off-by: Pali Rohár <pali@kernel.org>
Since commit 5d94cbd1dc ("scripts: Makefile.lib: generate
dsdt_generated.c instead of dsdt.c"), the file generated
is named dsdt_generated.c instead of dsdt.c.
So all files .gitignore referencing dsdt.c should be
upated with dsdt_generated.c.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The stdout-path property in the device tree does not necessarily
point at a serial device. On machines such as the Apple M1 laptops
where the serial port isn't easy to access and users expect to see
console output on the integrated display stdout-path may point at
the device tree node for the framebuffer for example.
If stdout-path does not point at a node for a serial device, the
serial_check_stdout() will not find a bound device and will drop
down into code that attempts to use lists_bind_fdt() to bind a
device anyway. However, that fallback code does not check that
the uclass of the device is UCLASS_SERIAL. So if stdout-path points
at the framebuffer instead of the serial device it will return a
UCLASS_VIDEO device. Since the code that calls this function
expects the returned device to be a UCLASS_SERIAL device, U-Boot
will crash as soon as it attempts to send output to the console.
Add a check here to verify that the uclass of the bound device
really is UCLASS_SERIAL. If it isn't, serial_check_stdout() will
return an error and serial_find_console_or_panic() will use the
serial device with sequence number 0 as the console and all is fine.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
When running against RC_OSC_32k, the watchdog may suffer from running
faster than expected, expiring earlier. The Linux kernel adds a 10%
margin to the timeout calculation by slowing down the read clock rate
accordingly. Do the same here, also to have comparable preset values
for both drivers.
Along this, fix the name of the local var holding to frequency - in Hz,
not kHz.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Stefan Roese <sr@denx.de>
If Armada 37xx watchdog is started before U-Boot then CNTR_CTRL_ACTIVE bit
is set, U-Boot armada-37xx-wdt.c driver fails to initialize and so U-Boot
is unable to use or kick this watchdog.
Do not check for CNTR_CTRL_ACTIVE bit and always initialize watchdog. Same
behavior is implemented in Linux kernel driver.
This change allows to activate watchdog in firmware which loads U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Since commit 492ee6b8d0 ("watchdog: wdt-uclass.c: handle all DM
watchdogs in watchdog_reset()"), all the watchdog are started when
the config WATCHDOG_AUTOSTART.
To avoid a binary choice none/all, a property u-boot,noautostart
may be added in the watchdog node of the u-boot device tree to not
autostart this watchdog.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
I've been handling "inofficially" the watchdog related patches for a few
years now. Let's make this official and add a tree for it and also add
myself here in the MAINTAINERS file.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Harald Seiler <hws@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since OpenSSL 1.1.0, EVP_MD_CTX_create() is EVP_MD_CTX_new()
EVP_MD_CTX_destroy() is EVP_MD_CTX_free()
EVP_MD_CTX_init() is EVP_MD_CTX_reset()
As there's no need to reset a newly created EVP_MD_CTX, moreover
EVP_DigestSignInit() does the reset, thus call to EVP_MD_CTX_init()
can be dropped.
As there's no need to reset an EVP_MD_CTX before it's destroyed,
as it will be reset by EVP_MD_CTX_free(), call to EVP_MD_CTX_reset()
is not needed and can be dropped.
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Based on looking at top contributors it was seen that top statistics from
top contributors don't include all contributions from different email
addresses. That's why I checked all top contributors are checked it.
git shortlog -n $START..$END -e -s
The patch is adding mapping for Bin Meng, Marek Vasut, Masahiro Yamada,
Michal Simek, Tom Rini, Wolfgang Denk.
And also use mapping for Stefan Roese and Wolfgang Denk to be properly
counted.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
If parameter -F is given but FIT support is missing, a NULL pointer might
dereferenced (Coverity CID 350249).
If incorrect parameters are given, provide a message and show usage.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Recent unrelated fixes (9876ae7db6) revealed that we were missing bits
from 2af181b53e in the IOT2050 dt. Add them, but only for main U-Boot.
SPL loads from QSPI only, thus cannot use DMA.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
We only want to call do_board_detect() if CONFIG_TI_I2C_BOARD_DETECT
is set. Same as done for am64.
This makes it possible to add a custom am65 based board design to
U-Boot that does not use this board detection mechanism.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Public documents about BootROM of some Marvell SoCs are available in the
public Web Archive. Put this information into source code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Testes proved that current kwboot version supports also Avanta SoCs.
It looks like that Avanta SoCs are using same kwbimage format as Armada.
Signed-off-by: Pali Rohár <pali@kernel.org>
Tested-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Document -D, -b, -d, -q and -s options.
Add common examples how to use kwboot.
Add information about Armada 38x BootROM bug for debug console mode and how
to workaround it.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Add all supported Armada SoCs and document -b and -d options in usage.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Marvell BootROM recognize only '\b' byte as backspace. Use terminfo
for retrieving current backspace sequence and replace any occurrence of
backspace sequence by the '\b' byte.
Reading terminfo database is possible via tigetstr() function from system
library libtinfo.so.*. So link kwboot with -ltinfo.
Normally terminfo functions are in <term.h> system header file. But this
header file conflicts with U-Boot "termios_linux.h" header file. So declare
terminfo functions manually.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
-d option is currently broken. In most cases BootROM does not detect this
message pattern. For sending debug message pattern it is needed to do same
steps as for boot message pattern.
Implement sending debug message pattern via same separate thread like it is
for boot message pattern.
Checking if BootROM entered into UART debug mode is different than
detecting UART boot mode. When in boot mode, BootROM sends xmodem NAK
bytes. When in debug mode, BootROM activates console echo and reply back
every written byte (extept \r\n which is interpreted as executing command
and \b which is interpreting as removing the last sent byte).
So in kwboot, check that BootROM send back at least 4 debug message
patterns as a echo reply for debug message patterns which kwboot is sending
in the loop.
Then there is another observation, if host writes too many bytes (as
command) then BootROM command line buffer may overflow after trying to
execute such long command. To workaround this overflow, it is enough to
remove bytes from the input line buffer by sending 3 \b bytes for every
sent character. So do it.
With this change, it is possbile to enter into the UART debug mode with
kwboot -d option.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
After BootROM successfully detects boot message pattern on UART it waits
until host stop sending data on UART. For example Armada 385 BootROM
requires that host does not send anything on UART at least 24 ms. If host
is still sending something then BootROM waits (possibly infinitely).
BootROM successfully detects boot message pattern if it receives it in
small period of time after power on.
So to ensure that host put BootROM into UART boot mode, host must send
continuous stream of boot message pattern with a small gap (for A385 at
least 24 ms) after series of pattern. But this gap cannot be too often or
too long to ensure that it does not cover whole BootROM time window when it
is detecting for boot message pattern.
Therefore it is needed to do following steps in cycle without any delay:
1. send series of boot message pattern over UART
2. wait until kernel transmit all data
3. sleep small period of time
At the same time, host needs to monitor input queue, data received on the
UART and checking if it contains NAK byte by which BootROM informs that
xmodem transfer is ready.
But it is not possible to wait until kernel transmit all data on UART and
at the same time in the one process to also wait for input data. This is
limitation of POSIX tty API and also by linux kernel that it does not
provide asynchronous function for waiting until all data are transmitted.
There is only synchronous variant tcdrain().
So to correctly implement this handshake on systems with linux kernel, it
is needed to use tcdrain() in separate thread.
Implement sending of boot message pattern in one thread and reading of
reply in the main thread. Use pthread library for threads.
This change makes UART booting on Armada 385 more reliable. It is possible
to start kwboot and power on board after minute and kwboot correctly put
board into UART boot mode.
Old implementation without separate thread has an issue that it read just
one byte from UART input queue and then it send 128 message pattern to the
output queue. If some noise was on UART then kwboot was not able to read
BootROM response as its input queue was just overflowed and kwboot was
sending more data than receiving.
This change basically fixed above issue too.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Function kwboot_debugmsg() is always called with kwboot_msg_debug as msg
and function kwboot_bootmsg() with kwboot_msg_debug as msg. Function
kwboot_bootmsg() is never called with NULL msg.
Simplify, cleanup and remove dead code.
No functional change.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Variable msg_req_delay is set but never used. So completely remove it.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Failure of kwboot_tty_send() and tcflush() functions is fatal, it does not
make sense to continue. So return error back to the caller like in other
places where are called these functions.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Commit 369e532691 ("ddr: marvell: a38x: allow board specific ODT
configuration") added the odt_config member to struct
mv_ddr_topology_map ahead of the clk_enable and ck_delay members. This
means that any boards that configured either of clk_enable or ck_delay
needed to have their board topology updated. This affects the x530 and
clearfog boards. Other A38x boards don't touch any of the trailing
members of mv_ddr_topology_map so don't need updating.
Fixes: 369e532691 ("ddr: marvell: a38x: allow board specific ODT configuration")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Stefan Roese <sr@denx.de>
Replace null pointer by pointer to device registers when calling
armada38x_rtc_write.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Stefan Roese <sr@denx.de>
The a3700_fdt_fix_pcie_regions() function still computes nonsense.
It computes the fixup offset from the PCI address taken from the first
row of the "ranges" array, which means that:
- PCI address must equal CPU address (otherwise the computed fix offset
will be wrong),
- the first row must contain the lowest address.
This is the case for the default device-tree, which is why we didn't
notice it.
It also adds the fixup offset to all PCI and CPU addresses, which is
wrong.
Instead:
1) The fixup offset must be computed from the CPU address, not PCI
address.
2) The fixup offset must be computed from the row containing the lowest
CPU address, which is not necessarily contained in the first row.
3) The PCI address - the address to which the PCIe controller remaps the
address space as seen from the point of view of the PCIe device -
must be fixed by the fix offset in the same way as the CPU address
only in the special case when the CPU adn PCI addresses are the same.
Same addresses means that remapping is disabled, and thus if we
change the CPU address, we need also to change the PCI address so
that the remapping is still disabled afterwards.
Consider an example:
The ranges entries contain:
PCI address CPU address
70000000 EA000000
E9000000 E9000000
EB000000 EB000000
By default CPU PCIe window is at: E8000000 - F0000000
Consider the case when TF-A moves it to: F2000000 - FA000000
Until now the function would take the PCI address of the first entry:
70000000, and the new base, F2000000, to compute the fix offset:
F2000000 - 70000000 = 82000000, and then add 8200000 to all addresses,
resulting in
PCI address CPU address
F2000000 6C000000
6B000000 6B000000
6D000000 6D000000
which is complete nonsense - none of the CPU addresses is in the
requested window.
Now it will take the lowest CPU address, which is in second row,
E9000000, and compute the fix offset F2000000 - E9000000 = 09000000,
and then add it to all CPU addresses and those PCI addresses which
equal to their corresponding CPU addresses, resulting in
PCI address CPU address
70000000 F3000000
F2000000 F2000000
F4000000 F4000000
where all of the CPU addresses are in the needed window.
Fixes: 4a82fca8e3 ("arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Enable ext4 write support in Turris Omnia's defconfig. Some users find
it useful.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Use "MVPCIE_" prefix instead of generic "PCIE_" prefix for pci_mvebu.c
specific macros. Define offset macros for Root Port registers and use
standard register macros from pci.h when accessing Root Port registers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Macro SELECT() is unused and struct mvebu_pcie field lane_mask is unused
too. Remove them.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Sometimes kwboot after quitting terminal prints error message:
terminal: Bad address
This is caused by trying to call write() syscall with count of (size_t)-1
bytes.
When quit sequence is split into more read() calls then number of input
bytes (nin) at the end of cycle can underflow and be negative. Fix it.
Fixes: de7514046e ("tools: kwboot: Fix detection of quit esc sequence")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
First set of u-boot-atmel fixes for the 2022.04 cycle:
This fixes set includes only a single fix for the Ethernet on sama7g5ek
board which is broken at the moment.
The F1C100s DT contains the wrong compatible string for the watchdog,
which breaks reset functionality.
Updating the DT goes via the Linux tree, but to allow reset
functionality meanwhile (useful for development!), disable SYSRESET for
now, to let the old-fashioned watchdog driver kick in and provide the
reset_cpu() implementation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Commit 88998f7775 ("arm: arm926ej-s: Add sunxi code") introduced
the ARM926 version of the code to save and restore some FEL state, to
be able to return to the BROM FEL code after the SPL has run.
However during review a change was made, that happened to mess up the
register restore part, so SCTLR and CPSR ended up with the wrong values,
breaking return to FEL.
Use the same offset that we actually save those registers to, to make
FEL booting actually work on the Lichee Pi Nano.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The SUNIV SoCs come with a sun6i-style SPI controller at the base address
of sun4i SPI controller. The module clock of the SPI controller is
missing which leaves us running directly from the AHB clock, which is
set to 200MHz.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[Icenowy: Original implementation]
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
[Jesse: adaptation to Upstream U-Boot]
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
In contrast to other Allwinner SoCs the F1C100s BROM does not store a
boot source indicator in the eGON header in SRAM. This leaves the SPL
guessing where we were exactly booted from, and for instance trying
the SD card first, even though we booted from SPI flash.
By inspecting the BROM code and by experimentation, Samuel found that the
top of the BROM stack contains unique pointers for each of the boot
sources, which we can use as a boot source indicator.
This patch removes the existing board_boot_order bodge and replace it
with a proper boot source indication function.
The only caveat is that this only works in the SPL, as the SPL header
gets overwritten with the exception vectors, once U-Boot proper takes
over. Always return MMC0 as the boot source, when called from U-Boot
proper, as a placeholder for now, until we find another way.
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Suggested-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Ensure there is a valid reset-gpio defined before using it.
Fixes: f9852acdce ("phy: nop-phy: Fix enabling reset")
Cc: Adam Ford <aford173@gmail.com>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
The BOOT_TARGET_DEVICES list for distro_bootcmd was hard-coded to assume
that all boot devices are available/enabled in the configuration,
thus ignoring the actual config settings. The config_distro_bootcmd.h
header file specifically has compile-time checks to detect such problems.
To allow disabling USB, SCSI, etc. in custom lx2160a board configs,
make it depend on the config settings and use only the enabled features.
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Simplify the binman config and fdt nodes by using the "@..-SEQ"
substitutions and CONFIG_OF_LIST.
Signed-off-by: Michael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set
enetaddr to a random value if not set and then pass the randomly
generated MAC address to linux.
This is bad for the following reasons:
(1) it makes it impossible for linux to detect this error
(2) linux won't trigger any fallback mechanism for the case where
it didn't find any valid MAC address
(3) a saveenv will store this randomly generated MAC address in the
environment
Probably, the user will also be unaware that something is wrong. He will
just get different MAC addresses on each reboot, asking himself why this
is the case.
As this board usually have a serial port, the user can just fix this by
setting the MAC address manually in the environment. Also disable the
netconsole just in case, because it cannot be guaranteed that it will
work in any case. After all, this was just a convenience option, because
the bootloader - right now - doesn't have the ability to read the MAC
address, which is stored in the OTP. But it is far more important to
have a clear view of whats wrong with a board and that means we can no
longer use this Kconfig option.
Signed-off-by: Michael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
They are no longer needed, because we now have proper driver support for
the sl28cpld management controller.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
This board has an internal watchdog which supervises the board startup.
Although, the initial state of the watchdog is configurable, it is
enabled by default. In board_late_init(), which means almost everything
worked as expected, disable the watchdog.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The SoC provides two additional watchdogs integrated in the SoC. Enable
support for these.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Enable the GPIO and watchdog driver. Don't start the watchdog
automatically, though.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Most of the time it is very useful to have the version of the board
management controller. Now that we have a driver, print it during
startup.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The current console output is:
DRAM: 4 GiB
DDR 4 GiB (DDR3, 32-bit, CL=11, ECC on)
The size is printed twice and we can save one line of console output if
we join both lines. The new output is as follows:
DRAM: 4 GiB (DDR3, 32-bit, CL=11, ECC on)
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The gpio block is part of the sl28cpld sl28cpld management controller.
There are three different flavors: the usual input and output where the
direction is configurable, but also input only and output only variants.
Signed-off-by: Michael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
The watchdog timer is part of the sl28cpld management controller. The
watchdog timer usually supervises the bootloader boot-up and if it bites
the failsafe bootloader will be activated. Apart from that it supports
the usual board level reset and one SMARC speciality: driving the
WDT_TIMEOUT# signal.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Add a multi-function device driver which will probe its children and
provides methods to access the device.
Signed-off-by: Michael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
The driver is currently using sizeof(op->cmd.opcode) in the op_len
calculation. Commit d15de62301 ("spi: spi-mem: allow specifying a
command's extension") changed op->cmd.opcode from one byte to two.
Instead, a new struct member op->cmd.nbytes is supposed to be used.
For regular commands op->cmd.nbytes will be one.
Commit d15de62301 ("spi: spi-mem: allow specifying a command's
extension") did update some drivers that overload the generic mem_ops()
implementation, but forgot to update dw_spi_mem_ops().
Calculating op_len incorrectly causes dw_spi_mem_ops() to misbehave, since
op_len is used to determine how many bytes that should be read/written.
On the canaan k210 board, this causes the probe of the SPI flash to fail.
Fix the op_len calculation in dw_spi_mem_ops(). Doing so results in
working SPI flash on the canaan k210 board.
Fixes: d15de62301 ("spi: spi-mem: allow specifying a command's extension")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
In the TI am65 device tree files there is no reset defined. Also
the Linux kernel driver uses devm_reset_control_get_optional_exclusive(..)
to get the reset.
Lets do the same as the kernel does and make thr reset optinal.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
