A '.update' extension does not get preserved by buildman, so change it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Michael Walle <michael@walle.cc>
Trying to boot a fitImage after a successful hab_auth_img operation
causes the following error:
## Loading kernel from FIT Image at 88000000 ...
Using 'conf-imx7d-smegw01.dtb' configuration
Trying 'kernel-1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x8800010c
Data Size: 9901752 Bytes = 9.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80800000
Entry Point: 0x80800000
Hash algo: sha256
Hash value: 28f8779bbf010780f16dd3d84ecb9b604c44c5c2cf7acd098c264a2d3f68e969
Verifying Hash Integrity ... sha256Error in SEC deq
CAAM was not setup properly or it is faulty error!
The reason for this error is that the BootROM uses the CAAM Job Ring 0,
so disable its node in U-Boot to avoid the resource conflict.
imx8m dtsi files also have the Job Ring 0 disable since the following
kernel commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch?h=v6.5&id=dc9c1ceb555ff661e6fc1081434600771f29657c
For a temporary solution, disable the Job Ring 0 in imx7s-u-boot.dtsi.
Reported-by: Eduard Strehlau <eduard@lionizers.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
The ivt_offset parameter is optional for both hab_auth_img_or_fail
and hab_auth_img commands.
Document it in their usage texts to make it clearer.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Since commit ea91031b2232 ("imx: hab: extend hab_auth_img to calculate
ivt_offset"), it is possible to call the hab_auth_img command without the
last ivt_offset argument.
Currently, calling hab_auth_img_or_fail without the last
ivt_offset parameter causes a failure and the command usage text is shown.
Fix this problem by adjusting the argc logic to allow
calling hab_auth_img_or_fail with only the address and size parameters.
This way, both hab_auth_img and hab_auth_img_or_fail have the same
behavior with respect to the allowed number of command parameters.
Signed-off-by: Eduard Strehlau <eduard@lionizers.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
If CMD_ELF disabled and IMX_BOOTAUX enabled, the u-boot building ends
up with a linking error [1]. Select LIB_ELF to fix the building
issue.
[1]
ld: /tmp/ccaF1rpv.ltrans0.ltrans.o: in function `do_bootaux':
arch/arm/mach-imx/imx_bootaux.c:108: undefined reference to `valid_elf_image'
Fixes: c0f037f6a2a ("mach-imx: bootaux: elf firmware support")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Remember where these end up so that we can pass this information on to
the EFI layer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When CONFIG_CMD_USB and CONFIG_USB are disabled, still some compilation
errors are seen as below.
In file included from include/configs/xilinx_zynqmp.h:173,
from include/config.h:3,
from include/common.h:16,
from env/common.c:10:
include/config_distro_bootcmd.h:302:9: error: expected '}' before 'BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:302:9: note: in definition of macro
'BOOTENV_DEV_NAME_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:77:41: note: in expansion of macro
'BOOTENV_DEV_NAME'
77 | # define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
func(USB, usb, 1)
| ^~~~
include/configs/xilinx_zynqmp.h:168:9: note: in expansion of macro
'BOOT_TARGET_DEVICES_USB'
168 | BOOT_TARGET_DEVICES_USB(func) \
| ^~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:454:25: note: in expansion of macro
'BOOT_TARGET_DEVICES'
454 | "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
| ^~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:474:9: note: in expansion of macro
'BOOTENV_BOOT_TARGETS'
474 | BOOTENV_BOOT_TARGETS \
| ^~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:179:9: note: in expansion of macro
'BOOTENV'
179 | BOOTENV
| ^~~~~~~
include/env_default.h:120:9: note: in expansion of macro
'CFG_EXTRA_ENV_SETTINGS'
120 | CFG_EXTRA_ENV_SETTINGS
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from env/common.c:32:
include/env_default.h:27:36: note: to match this '{'
27 | const char default_environment[] = {
| ^
scripts/Makefile.build:256: recipe for target 'env/common.o' failed
make[1]: *** [env/common.o] Error 1
Makefile:1853: recipe for target 'env' failed
make: *** [env] Error 2
make: *** Waiting for unfinished jobs....
Add CONFIG_USB_STORAGE as dependency for USB related macro's such as
BOOT_TARGET_DEVICES_USB() and DFU_DEFAULT_POLL_TIMEOUT and
CONFIG_THOR_RESET_OFF.
Remove CONFIG_ZYNQMP_USB from Kconfig and also from defconfig since it
is not used anywhere else.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230904031528.11817-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Correct the i2c address for si570 oscillator that generates the si570_user1
clock. i2c address was changed by commit b6a8c603d680 ("arm64: zynqmp: Fix
i2c addresses for vck190 SC") because address in node name wasn't aligned
with reg property. But actual 0x5f address is correct which is quite rare
because all other si570s are at 0x5d.
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/6f31881b0e2dd657f0d4ff0869c009c2e1224f22.1694441445.git.michal.simek@amd.com
Added no-wp DT property in OSPI flash node for all board dts & dtsi files
on which the WP# signal of the OSPI flash device is not connected. If this
property is set, then the software will avoid setting the status register
write disable (SRWD) bit in status register during status register
write operation.
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/7e88dd7b9306bdf0738b2248bf9017e1997d25dc.1694441445.git.michal.simek@amd.com
xlnx,mio_bank was used in past but it was renamed to xlnx,mio-bank because
'_' in property shoudln't be used. There is no impact on the platform
because if the properly is not defined bank 0 is default. Bank 0 and 1 have
the same configuration that's why there shouldn't be any issue.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/ace68d4b7701d1606a85cb18242409fce941b363.1694441445.git.michal.simek@amd.com
Now that the zynqmp pinctrl driver supports the tri-state registers, make
sure that the pins requiring output-enable are configured appropriately for
SOMs.
Without it, all tristate setting for MIOs, which are not related to SOM
itself, are using default configuration which is not correct setting.
It means SDs, USBs, ethernet, etc. are not working properly.
In past it was fixed through calling tristate configuration via bootcmd:
usb_init=mw 0xFF180208 2020
kv260_gem3=mw 0xFF18020C 0xFC0 && gpio toggle gpio@ff0a000038 && \
gpio toggle gpio@ff0a000038
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/7ecd98b2a302c5c6628e0234482f23c38e721fd6.1693492064.git.michal.simek@amd.com
Revision 2 is SW compatible with revision 1 but it is necessary to reflect
it in model and compatible properties which are parsed by user space.
Rev 2 has improved a power on boot reset and MIO34 shutdown glich
improvement done via an additional filter in the GreenPak chip.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/6b9e68ebfb436da391daeb147f2a9985ac984c0c.1692951005.git.michal.simek@amd.com
All si570 mgt chips have factory default 156.25MHz but DT changed it to
148.5MHz. After tracking it is pretty much c&p fault taken from Zynq
zc702/zc706 boards where 148.5MHz was setup as default because it was
requirement for AD7511 chip available on these boards.
ZynqMP board don't contain this chip that's why factory default frequency
can be used.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/c052ddf39e392e97f87f1c57ea06f3508733c672.1692947486.git.michal.simek@amd.com
This moves the aes operation that is performed by the pmu into a
separate file. This way it can be called not just from the shell
command, but also e.g. from board initialization code.
Signed-off-by: Christian Taedcke <christian.taedcke@weidmueller.com>
Link: https://lore.kernel.org/r/20230725072658.16341-1-christian.taedcke-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The DTS uses constants for SERDES MUX idle state values which were earlier
provided as bindings header. But they are unsuitable for bindings.
So move these constants in a header next to DTS.
NOTE: sync with v6.6-rc1 will bring in this change naturally.
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce the new serdes header from kernel v6.6-rc1
The DTS uses constants for SERDES MUX idle state values which were earlier
provided as bindings header. But they are unsuitable for bindings.
So move these constants in a header next to DTS.
Signed-off-by: Nishanth Menon <nm@ti.com>
In 2cb43ef1c223 ("usb: ether: Fix error handling in usb_ether_init") the error
handling of usb_ether_init() was changed. Not a single other call site of this
function checks its return value, therefore follow suit in the am33xx code.
Do not cause the boot to halt if the usb gadget ethernet initialization fails:
initcall sequence 9ffdbd84 failed at call 808024b9 (err=-19)
### ERROR ### Please RESET the board ###
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Reviewed-by: Michal Suchánek <msuchanek@suse.de>
Add compatible values to Ethernet PHY subnodes representing Micrel
KSZ9031 PHYs on R-Car Gen3 Salvator-X boards. This allows software
to identify the PHY model at any time, regardless of the state of
the PHY reset line.
This is a fix for missed addition of these properties on Salvator-X
boards.
Ported from Linux kernel commit 722d55f3a9bd810f3a1a31916cc74e2915a994ce .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The usb_gadget_handle_interrupts() is no longer used anywhere,
replace the remaining uses with dm_usb_gadget_handle_interrupts()
which takes udevice as a parameter.
Some of the UDC drivers currently ignore the index parameter altogether,
those also ignore the udevice and have to be reworked. Other like the
dwc3_uboot_handle_interrupt() had to be switched from index to udevice
look up to avoid breakage.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on khadas vim3
Signed-off-by: Marek Vasut <marex@denx.de>
To have the WDIOF_CARDRESET support for the TI AM65x platform watchdog,
this patch reserves some memories, which indicate if the current boot due
to a watchdog reset.
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
Update the DDR settings to those generated using 0.10 version of Jacinto
7 DDRSS Register Configuration tool.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
BeagleBoard.org BeaglePlay is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM625
SoC that allows you to create connected devices that work even at long
distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
Expansion is provided over open standards based mikroBUS, Grove and
QWIIC headers among other interfaces.
This board family can be identified by the 24c32 eeprom:
[aa 55 33 ee 01 37 00 10 2e 00 42 45 41 47 4c 45 |.U3..7....BEAGLE|]
[50 4c 41 59 2d 41 30 2d 00 00 30 32 30 30 37 38 |PLAY-A0-..020078|]
https://beagleplay.org/https://git.beagleboard.org/beagleplay/beagleplay
baseline of base device tree is v6.5-rc1.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Co-developed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
While at this, drop the extraneous whitespace.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
The erratum is called locally, make it static, drop the #ifdeffery since
it will only be called in R5 build and mark it potentially unused to
stop compiler screaming at us.
While at this, drop the redundant return for a void function.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Drop the #ifdeffery and use IS_ENABLED() inline check and let the compiler
do it's thing.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Clean the function up a bit further. Return immediately on match
and return ARRAY_SIZE() - 1 on failure. Add proper comment in that
case.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
This platform is behind on migrations (it is the sole user of the oldest
legacy version of the USB gadget stack and is long overdue for
migration) and with Pali no longer being a maintainer, we remove this
platform.
Signed-off-by: Tom Rini <trini@konsulko.com>
If dram_init_banksize() is called from SPL, the rom_pointer, at that
point, is not correctly initialized. This causes wrong calculation of
DRAM start and size in dram_init_banksize(). The issue became apparent
only in Falcon Mode. Added an extra condition to prevent using
rom_pointer in SPL.
Signed-off-by: Elena Popa <elena.popa@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Use the misc_init_f event instead, which is designed for this purpose.
All boards with CONFIG_VID already enable CONFIG_EVENT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Very few of the existing event-spy records use the arguments they are
passed. Update them to use a simple spy instead, to simplify the code.
Where an adaptor function is currently used, remove it where possible.
Signed-off-by: Simon Glass <sjg@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmTu+QMcHGV1Z2VuLmhy
aXN0ZXZAY29sbGFib3JhLmNvbQAKCRAesx4CDqwvyFqVB/9z5lV4zhqWYiQ+wNZL
Gxs3//DSS5iVHU+xaPRrYQT99Yn2/kfM2LeQ4REBOaOTP7IX2ewmOEro4OUViFuC
kt/WnHD0XzN+2o8akIdVC5YudgVcuX751SQtp5dqcbN6FylSH010+YIZTvaJoNQn
+Wny1ZZhpuNJJEPvLxE/eiJ3jFwvEAjC+jH328uQIeSLknPh93hGJOFc/02F0O2o
s96J1/VZ4qvvQKYw0sgNtGb/0Og7V0RLW27+RfwhH4XJvAIv/A6MioTyRaCS2h7H
tzj/hFXbzGtu+AqrEtMgNjzC7vAx+0266P/Zx/DOWKoWLDIYkWSLpYKLut0E6CUe
+fcB
=L/iw
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2023.10-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2023.10 cycle:
This feature set includes a new board sama5d29 Curiosity, and various
fixes and alignments for sam9x60 and sam9x60 curiosity board.
Add a newline at the end of the dts, without which the build fails
when including a dtsi file.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Copied as is from Linux Kernel release v6.4.
(dts file is still the same in Linux v6.5-rc7 but was moved to vendor
sub-directories with v6.5-rc1.)
Button works out of the box now if the following config options are
enabled: CONFIG_BUTTON, CONFIG_BUTTON_GPIO, CONFIG_CMD_BUTTON,
CONFIG_DM_GPIO.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
If CONFIG_LED and CONFIG_LED_GPIO are enabled, it is not necessary to
initialize the RGB LED on the board by manually setting hardcoded GPIOs
anymore. Everything is well defined in dts and can be used like on
boards of other vendors.
Keep the old behaviour as fallback, though.
With all this in place enabling CONFIG_CMD_LED gives us a working 'led'
command on the U-Boot shell.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Copied as is from Linux Kernel release v6.4.
(dts file is still the same in Linux v6.5-rc7 but was moved to vendor
sub-directories with v6.5-rc1.)
Signed-off-by: Alexander Dahl <ada@thorsis.com>
This reverts commit c5b68ef8af3c2f515c1f5b8d63a69359a85d753b.
CONFIG_OPTEE_TZDRAM_SIZE is used by imx6-based SoCs as well. Move the
option back.
Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Adding a phandle to a template node is not allowed, since when the node is
instantiated multiple times, we end up with duplicate phandles.
Drop this invalid constructs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Tim Harvey <tharvey@gateworks.com>
Ethernet on Bananapi-r3 is broken after
commit bd70f3cea353 ("net: mediatek: add support for SGMII 1Gbps auto-negotiation mode")
because changes from this commit were not applied to bpi-r3 devicetree too:
commit aef54ea16cac ("arm: dts: medaitek: convert gmac link mode to 2500base-x")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Weijie Gao <weijie.gao@mediatek.com>
CFG_STM32MP1_SCMI_SHM_SYSRAM will be disabled by default for STM32MP13x
SoCs in next OP-TEE version and the OP-TEE SMCI server uses the OP-TEE
native shared memory registered by clients.
To be compatible by default with this configuration this patch removes
the shared memory in the SCMI configuration and the associated reserved
memory in SRAM.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
