Move the omap3 beagle to the beagle vendor folder representing
BeagleBoard.org platforms.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Move beagleplay support away from ti/am62x to it's own beagle vendor
folder.
This forms the starting point for new beagle platforms added under it's
own board vendor folder.
As part of this create all the associated files with a bare minimum
beagleplay.c file.
Suggested-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
[trini: Update k3-binman.dtsi to use full path to scheme.yaml now]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add am62x_beagleplay_* defconfig customized for the configuration of
BeaglePlay and drop the config fragments.
This is in preparation for dropping the dependency on ti vendor folder
entirely.
Signed-off-by: Nishanth Menon <nm@ti.com>
With the upcoming folder separation, there is no further need to depend
on am625-binman.dtsi. Duplicate the existing definitions to u-boot.dtsi
and r5.dts as appropriate.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
When using include directives within a section that is included by non
TI board rst file, k3.rst and other include paths need to be relative to
doc/board/ base.
Signed-off-by: Nishanth Menon <nm@ti.com>
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Kernel commit 1b77265626a4 ("arm64: dts: ti: k3-j7200-mcu-wakeup: Add
HyperBus node") was merged to kernel without its dependent patch [1].
Similar fix is needed in U-Boot, and hbmc currently breaks boot. Till
this gets fixed in U-Boot, disable the config by default so that the
hbmc probe that happens in board/ti/j721e/evm.c will not take place
and lead to boot failure.
This is similar to the approach in commit 5b2671594b ("configs:
j721e: Remove HBMC_AM654 config"), introduced to j7200 evm platform.
[1] https://lore.kernel.org/all/20230424184810.29453-1-afd@ti.com/
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Commit 5019170970 ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b36 ("arm: mach-k3: am625: Add support for
UDA FS"). 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.
Signed-off-by: Nishanth Menon <nm@ti.com>
Enable SOC_K3_J721E_J7200 when board is J7200 EVM - this allows us to
differentiate J7200 platform cleanly in board independent codebase.
Signed-off-by: Nishanth Menon <nm@ti.com>
J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.
Signed-off-by: Nishanth Menon <nm@ti.com>
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Add explicit boot_targets to indicate the specific boot sequence to
follow.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Manorit Chawdhry <m-chawdhry@ti.com>
This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Andrew Davis <afd@ti.com>
SYSFW is only ever loaded by the R5 core, move the code into that
directory. While here also move the related Kconfig symbols.
Signed-off-by: Andrew Davis <afd@ti.com>
The kconfig option SPL means this build supports SPL but not that
this build is SPL, nor that this build is the SPL running on R5.
For options that are for R5 SPL use CPU_V7R.
Signed-off-by: Andrew Davis <afd@ti.com>
This makes it clear these are only to be used by the R5 builds of SPL.
And this will be used to later more cleanly split the two builds.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
Currently the K3 selection for TARGET boards does not depend on the SoC
for which it is based. This leds to the odd ability to select for instance
both SOC_K3_AM625 and TARGET_J721E_A72_EVM.
To fix this the target choice should depend on the matching SOC config.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Checking if variable chip is NULL after dereferencing it makes no sense.
As discribed in [1] it is not expected that the variable can ever be NULL.
[1] Re: [PATCH] tpm: avoid NULL pointer dereference in tpm_tis_send()
https://lore.kernel.org/u-boot/YaFwDtKKYRr7qzWc@apalos.home/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.
With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.
Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Marek Vasut <marex@denx.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAmVYdjgACgkQgS8AYozs
+qLAzBAAwgxr150Bpi9mRWgfJZVPes0FXWdcsb4yBC1lc5BEcGvLphW0Efa+N6SH
8s39dTdM/fnn3TlReshh6IYk1Lx7MjzgrNibk4tB7MhiGrAI0bkSPZgtJoCD/xgs
7zD3JI9Xe667MuEbhFqX8igVMjfvTZAQv5A5NGnB9zn3mvXdTVyoOgQUU5EDwM6c
+kv54FGKbztiJeyC8zDzFCuUw2jtpjXSPfzDbVTzQd4Q0joZW7Gkbsg0xEZ2P9qY
W3TiBXOg3ijISMsC3nhlkbkhuFhKA42mPl5ZtXb+8pBWLDd8Ldl36+KGFGh2SaEw
XEQKYZDAV0Bg+y0++6Q/TcnfYN6V9v0nZhfrt1xmVHKqf3KEdJ4j5axSDnP+0zt/
M0j0d4dc5Nm7jQ+YkRViunABMCRGm/0zFUOguN1hZ3pujTJkYIou29JgYdlc0fZg
E/eJxsVETkFi1BhNuSInGWVCCYE2IPBnXjbnbDf2enXIejfK5M43JsHcS6yj8eot
wg0B2xd1w2GbfijPslHvoNrVKB8qaceJiY2ybx6RxgCphSHPemrJ5dnFy6+HK9Rv
KlGWYF5H7TWSzubpFMnt0eVQmXKIP/NdpR18eq7R3AOA4/fT14WaHfg8vUzL1KJE
64jdMOo/5tfpZKcPF0PtUrjudBZzWgDLxltgZPri14AxMFnSV1g=
=Ddau
-----END PGP SIGNATURE-----
Merge tag 'efi-next-18112023' of https://source.denx.de/u-boot/custodians/u-boot-tpm into next
EFI HTTP Boot is currently supported by using a combination of
wget, blkmap and bootefi commands. The user has to download the
image, mount it using blkmap and then execute the efi installer
using bootefi.
This series simplifies the user experience. Instead of doing all the
steps manually, users can now enable a new Kconfig (EFI_HTTP_BOOT)
which will select wget, blkmap and dns options. They can then use
efidebug command to add a boot option for the EFI Bootmanager using
=> efidebug boot add -u 3 netinst http://<path>
=> efidebug boot order 3
=> bootefi bootmgr
The boot manager will automatically download and mount the image.
Once it's mounted it will locate and launch the installer.
It's worth noting that this rarely fails, but the reason is irrelevant
to the current patchset. More information can be found here
https://lore.kernel.org/u-boot/CAOMZO5CoduEgwgdQiybmoKh6qQZOezUtRRQO4ecaGdZBBz5dDw@mail.gmail.c
om/
The tl;dr is that wget sometimes fails to download the file correctly
or set the size env variables. We expect all these to be solved once
LWIP is stable and pulled
This adds the URI device path option for 'boot add' subcommand.
User can add the URI load option for downloading ISO image file
or EFI application through network. Currently HTTP is only supported.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This supports to boot from the URI device path.
When user selects the URI device path, bootmgr downloads
the file using wget into the address specified by loadaddr
env variable.
If the file is .iso or .img file, mount the image with blkmap
then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
Since boot option indicating the default file is automatically
created when new disk is detected, system can boot by selecting
the automatically created blkmap boot option.
If the file is PE-COFF file, load and start the downloaded file.
The buffer used to download the ISO image file must be
reserved to avoid the unintended access to the image and
expose the ramdisk to the OS.
For PE-COFF file case, this memory reservation is done
in LoadImage Boot Service.
[Ilias fix a few memory leaks by replacing returns with gotos]
Lore: https://lore.kernel.org/u-boot/20231110042542.3797301-1-masahisa.kojima@linaro.org/T/#mbac31da301ff465b60894b38f3a587b2868cf817
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When the image loaded by efibootmgr returns, efibootmgr
needs to clean the resources. Adding the event of returning
to efibootmgr is useful to simplify the implementation.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
const classifier is missing in EventGroup parameter of
CreateEventEx(). Fix it to remove the compiler warning.
NotifyContext parameter of CreateEventEx() is also defined
with const in UEFI specification, but NotifyContext parameter
of CreateEvent() is defined without const.
Since current implementation calls the common efi_create_event()
function from both CreateEventEx() and CreateEvent() services,
NotifyContext parameter leaves as is.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Changes for complying to EFI spec §3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.
Please note that currently the function 'efi_disk_remove' has no
ability to distinguish below two scenarios
a) Unplugging of a removable media under U-Boot
b) U-Boot exiting and booting an OS
Thus currently the boot variables management is not added into
'efi_disk_remove' to avoid boot options being added/erased
repeatedly under scenario b) during power cycles
See TODO comments under function 'efi_disk_remove' for more details
The original efi_secboot tests expect that BootOrder EFI variable
is not defined. With this commit, the BootOrder EFI variable is
automatically added when the disk is detected. The original
efi_secboot tests end up with unexpected failure.
The efi_secboot tests need to be modified to explicitly set
the BootOrder EFI variable.
squashfs and erofs ls tests are also affected by this modification,
need to clear the previous state before squashfs ls test starts.
Co-developed-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Joao Marcos Costa <jmcosta944@gmail.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
User needs to call several functions to create the ramdisk
with blkmap.
This adds the utility function to create blkmap device and
mount the ramdisk.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Current wget takes the target uri in this format:
"<http server ip>:<file path>" e.g.) 192.168.1.1:/bar
The http server ip address must be resolved before
calling wget.
This commit adds the utility function runs wget with dhs.
User can call wget with the uri like "http://foo/bar".
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This introduces the valid range check to store the received
blocks using lmb. The same logic is implemented in tftp.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This reverts commit 6cdf6b7a34. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit 836b8d4b20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit c1da6fdb5c. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
