Add remoteproc config options to enable remoteproc drivers by
default as per what remotproc subsystem is supported on each
SoC.
Signed-off-by: Judith Mendez <jm@ti.com>
Enable CMD_REMOTEPROC by default if building for K3 ARCH so
that it does not have to be defined in each board defconfig
file.
Signed-off-by: Judith Mendez <jm@ti.com>
If building for v7R and K3 architecture, enable SPL
remoteproc so that it does not have to be defined in each
board defconfig file.
Signed-off-by: Judith Mendez <jm@ti.com>
If SYS_K3_SPL_ATF is enabled, for K3 ARCH enable the
remoteproc ARM64 driver by default so that it does not
have to be defined in each board defconfig file.
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Add remoteproc specific env support for am62px device. If the
remoteproc CMD is defined, include the K3 remoteproc environment.
Also define rproc_fw_binaries which holds a list of remoteproc FW
binaries for u-boot loading of remote cores.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Add remoteproc specific env support for am62x device. If the
remoteproc CMD is defined, include the K3 remoteproc environment.
Also define rproc_fw_binaries which holds a list of remoteproc FW
binaries for u-boot loading of remote cores.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Add remoteproc specific env support for am64x device. If the
remoteproc CMD is defined, include the K3 remoteproc environment.
Also define rproc_fw_binaries which holds a list of remoteproc FW
binaries for u-boot loading of remote cores.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
AM64x SoCs have two R5F clusters in the main power domain.
Extend support for R5F remote proc driver on AM64x with compatible
strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Andrew Davis <afd@ti.com>
Some K3 devices like AM64, AM62 devices have a M4 processor in MCU
voltage domain.
Add a remote proc driver to support this subsystem to be able to load
and boot the M4 core.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[Ryan: Fix implicitly include warning]
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
[Judith: Cleanup driver, fix warnings, remove lreset logic]
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Andrew Davis <afd@ti.com>
Judith Mendez <jm@ti.com> says:
This patch series adds config options for Sitara K3 boards
to support MMC UHS modes.
While testing with SD card boot and eMMC boot,
found missing eMMC boot support for am62ax in am62a7_init,
patch 1/7, and missing config option to support eMMC boot.
While we are here, for am62ax, enable config option to
change MMC bus modes and enable r5 SDHCI ADMA for faster boot
time.
Also for all k3 Sitara boards, cleanup MMC ENV configs that
are no longer needed since we no longer load env from MMC
device.
Link: https://lore.kernel.org/r/20241220203704.2076499-1-jm@ti.com
Add the basic 'hello world ta' command which increment
of the value passed. This provides easy test for
establishing a session with OP-TEE TA and verify.
It includes following "hello world ta" subcommands:
optee hello; default value '0' is passed and gets incremented.
optee hello <value>; value to increment via OP-TEE HELLO
WORLD TA.
To enable the OP-TEE side HELLO WORLD example please refer
https://optee.readthedocs.io/en/latest/building/gits/optee_examples/optee_examples.html
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Enable MMC_SPEED_MODE_SET config option in defconfig to enable
changing MMC bus modes with mmc rescan for am62ax device.
Signed-off-by: Judith Mendez <jm@ti.com>
When a successful neighbor advertisement is received, the ethernet
address should be saved for later use to avoid having to redo the
neighbor discovery process.
For example, with TFTP the address should get saved into
"net_server_ethaddr". This is being done correctly with ARP for IPv4,
but not for neighbor discovery with IPv6.
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
timeout_count is never reset once a tftpput transfer has started. If for
whatever reason timeouts occur frequently, but the server keeps replying
nonetheless, the transfer may be needlessly aborted.
Reset timer_count on reception of an ACK to avoid this situation.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Linux DTS compatible MDIO bitbanging driver.
Both clause 22 and clause 45 MDIO supported and validated.
Heavily based on the Linux drivers (more or less the same code base).
Signed-off-by: Markus Gothe <markus.gothe@genexis.eu>
This reverts commit 431be621c6.
Section 3.3 of Reduced Gigabit Media Independent Interface (RGMII)
Version 2.0 (4/1/2002) details that a PHYs using a ~2ns internal delay
are referred to as RGMII-ID. This internal delay is optional.
Page 147-148 of the Marvell Doc. No. MV-S107146-U0 Rev. F details
timings of the RX/TX delays. We see that with the TX/RX_CLK delay
enabled, our RX/TX_CTL signal is shifted w.r.t CLK to reflect the delay
added.
In 431be62 there is no timing difference between RGMII and RGMII-ID, and
so programmers wanting to explicitly set their PHY to RGMII will find
that delay added anyway. This could throw off timing if that internal
delay is undesired.
We should be handling all 4 possible RGMII cases of PHY_INTERFACE_MODE:
RGMII, RGMII_ID, RGMII_TXID, and RGMII_RXID. Reverting 431be62
implements this.
See also m88e1111_config_init_rgmii_delays in the equivalent driver in
Linux (drivers/net/phy/marvell.c), which does not set these delays in
RGMII mode.
68e6eca was tested out on an 88E1512 PHY in RGMII-ID mode. This
reversion has been tested by myself on an 88E1518 in RGMII-ID mode. This
patch affects boards using this driver in "rgmii" mode, as the internal
delay will no longer be enabled. Namely kikwood-nsa310s.
Signed-off-by: Rufus Segar <rhs@riseup.net>
We have a some boards that rarely starts networking abnormally, so there are
many timeouts during file transfer. In the same time there is a normal transfer
between timeouts. In this case we can continue transfer (instead of connection
aborting) by just clearing timeout counter on every successful block.
This patch does not affect the case when several timeouts happen one after
another. The transfer will be aborted. Thus the transfer will be
continued in the case of unstable link, but will be aborted in the case
of inaccessible server.
Feature downside: it may greatly slowdown (instead of abort) file transfer
in the case of unstable link.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
When converting a U-Boot trace records file to ftrace function graph
format for use by trace-cmd ('proftool -f funcgraph dump-ftrace'), the
time associated to each function is incorrectly saved in microseconds
instead of nanoseconds. Multuply the value by 1000 to fix the issue.
With this change, the trace-cmd output looks consistent. Here is an
example with udelay(25) added to mem_malloc_init() as a test case:
$ ./tools/proftool -m System.map -t /tmp/trace.bin -f funcgraph \
dump-ftrace -o /tmp/trace.dat
$ trace-cmd report /tmp/trace.dat >/tmp/trace.log
$ vi /tmp/trace.log
[...]
u-boot-1 [000] 6.719659: funcgraph_entry: | mem_malloc_init() {
u-boot-1 [000] 6.719659: funcgraph_entry: | udelay() {
u-boot-1 [000] 6.719660: funcgraph_entry: | schedule() {
u-boot-1 [000] 6.719660: funcgraph_entry: | cyclic_run() {
u-boot-1 [000] 6.719660: funcgraph_entry: 1.000 us | cyclic_get_list();
u-boot-1 [000] 6.719661: funcgraph_exit: 1.000 us | }
u-boot-1 [000] 6.719661: funcgraph_exit: 1.000 us | }
u-boot-1 [000] 6.719661: funcgraph_entry: | __udelay() {
u-boot-1 [000] 6.719662: funcgraph_entry: 0.000 us | usec_to_tick();
u-boot-1 [000] 6.719687: funcgraph_exit: + 26.000 us | }
u-boot-1 [000] 6.719687: funcgraph_exit: + 28.000 us | }
u-boot-1 [000] 6.719687: funcgraph_entry: # 37971.000 us | memset();
u-boot-1 [000] 6.757658: funcgraph_exit: # 37999.000 us | }
u-boot-1 [000] 6.757658: funcgraph_exit: # 38000.000 us | }
In the above dump, the udelay() call is reported as taking 26 us which
is consistent with the timestamps (6.719687 - 6.719659 = 0.000026).
Without this patch we would have "0.026 us" instead of "+ 26.000 us".
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Move to using OF_UPSTREAM config and thus using the devicetree
subtree and remove unused device tree files.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Currently the driver relies on bootph flag to probe it during PRE_RELOC
stage but with the upcoming cleanup of v6.13, we don't have the bootph
property in the parent nodes anymore and ti_sci driver being one of the
parent nodes required during SPL stage would end up hampering the probe
model [0].
Add DM_FLAG_PRE_RELOC to ti_sci driver for mitigating this issue.
[0]: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/21
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The Texas Instruments Foundational Security (TIFS) firmware must match
the security level configured on the SoC. To boot Security Enforced (SE)
variants of the AM62Px, add another tiboot3 build which packages the
Security Enforced (SE) firmware variant for AM62Px SoCs.
Signed-off-by: Bryan Brattlof <bb@ti.com>
OSPI Boot requires overrides specific to R5 and also
to use DMA in R5 SPL stage the DM_TIFS needs to be used.
Add the corresponding overrides for R5 SPL stage.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
The wget command currently cannot work correctly with mtk_eth driver.
This patch fixed this by increase DMA ring size and invalidate ring data
after use.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Enable GDMA cpu bridge only when 10Gb interface is enabled for GMAC other
than GMAC0, or when MT7988 internal switch is used.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Not all platforms supports sgmii and/or usxgmii. So we add Kconfig
options for these features and enable them only for supported
platforms.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
MT7629 need extra setting for gmac2 to work. So additional
capability is added for mt7629 to handle this case.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Unlike other platforms, mt7622 has only one SGMII and it can be
attached to either gmac1 or gmac2. So the register field of the
sgmii selection differs from other platforms as newer platforms can
control each sgmii individually.
This patch adds a new capability for mt7622 to handle this case.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The register field for SGMII speed selection is a 2-bit field with
value 0 for 1Gbps and 1 for 2.5Gbps (2/3 are reserved).
So it's necessary to set both bits instead of just setting/clearing
only the lower bit.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Judith MendezandTom Rini
Hari NagallaandTom Rini
Venkatesh Yadav AbbarapuandTom Rini
Vignesh RaghavendraandTom Rini
Sean EdmondandTom Rini
Jerome ForissierandTom Rini
Frank SaeandTom Rini
Heinrich SchuchardtandTom Rini
Markus GotheandTom Rini
Rufus SegarandTom Rini
Mikhail KshevetskiyandTom Rini
Udit KumarandTom Rini
Manorit ChawdhryandTom Rini
Bryan BrattlofandTom Rini
Vaishnav AchathandTom Rini
Weijie GaoandTom Rini