In this case the value seems save to pass to os_free(). Add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 165109)
In tpm_sendrecv_command() the command buffer is passed in. If a mistake is
somehow made in setting this up, the size could be out of range. Add a
sanity check for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 331152)
The width is set up in single_of_to_plat() and can only have three values,
all of which result in a non-zero divisor. Add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 331154)
At present the return value of ofnode_get_property() is not checked, which
causes a coverity warning. While we are here, use logging for the errors.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 331157)
Update dm_dump_drivers() to use the return value from uclass_get() to
check the validity of uc. This is equivalent and should be more attractive
to Coverity.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 316601)
The devres_alloc() function is intended to avoid the need for freeing
memory, although in practice it may not be enabled, thus leading to a true
leak.
Nevertheless this is intended. Add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 312951)
The devres_alloc() function is intended to avoid the need for freeing
memory, although in practice it may not be enabled, thus leading to a true
leak.
Nevertheless this is intended. Add a comment to explain this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 312952)
This value is either 0 for success or -1 for error. Coverity reports that
"ret" is passed to a parameter that cannot be negative, pointing to the
condition 'if (ret < 0)'.
Adjust it to just check for non-zero and avoid showing -1 in the error
message, which is pointless. Perhaps these changes will molify Coverity.
Reported-by: Coverity (CID: 312956)
Signed-off-by: Simon Glass <sjg@chromium.org>
This cannot actually fail, but check the value anyway to keep coverity
happy.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 316351)
At present if ifname is exactly IFNAMSIZ characters then it will result
in an unterminated string. Fix this by using strlcpy() instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 316358)
Acked-by: Ramon Fried <rfried.dev@gmail.com>
Unfortunately for testing is required qflasher which works only in 32-bit
x86 mode. Apparently 64-bit x86 Azure CI has no problems as it has
preinstalled 32-bit libraries and can execute also 32-bit x86 executables.
This change just show human readable output why nokia_rx51_test.sh test
script fails.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210618133108.32497-1-pali@kernel.org
By default bootmenu is loaded only from eMMC. After this change U-Boot
first tries to load bootmenu from uSD card and if it fails then fallback to
eMMC. People want to boot alternative OS from removable uSD without need to
modify eMMC content. So this backward compatible change allows it.
Part of this change is also optimization of trymmc* macros so they can be
used in preboot macro for loading bootmenu.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210618132704.32066-2-pali@kernel.org
Enable U-Boot bootz command and update env scripts to try loading also
zImage file and to try booting via bootz command.
Update also lowlevel_init.S code for checking validity of zImage magic to
correctly relocate kernel in zImage format.
This change allows U-Boot to directly boot Linux kernel without need for
converting kernel image into U-Boot uImage format.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210618132704.32066-1-pali@kernel.org
Add voltage and thermal management (VTM) node. The efuse values for the
OPPs are stored under the VTM, and is needed for AVS class 0 support.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210714205300.17424-4-g-tammana@ti.com
TI J7200 EVM has lp876441 pmic that is similar to tps65941. Add support
for same with existing driver with new compatible.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Link: https://lore.kernel.org/r/20210714205300.17424-2-g-tammana@ti.com
Swap out the TI-centric "envboot" logic for the generic distro_bootcmd
logic for the bootcmd we run before trying to do something more complex
involving additional firmware, etc.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210713141139.15183-1-trini@konsulko.com
The usbtty functionality is not currently used on these two platforms,
disable it.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210708014348.4010-1-trini@konsulko.com
Swap out the TI-centric "envboot" logic for the generic distro_bootcmd
logic for the bootcmd we run before trying to do something more complex
involving additional firmware, etc.
Cc: Lokesh Vutla <lokeshvutla@ti.com> (maintainer:J721E BOARD)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210701142743.26190-1-trini@konsulko.com
Remove the environment support for various legacy boot methods. With
this, we will now default to booting any distribution that follows the
generic distro boot framework and no longer attempt to boot various
legacy (to this SoC) scripts/etc. Note that if we do not find anything
here we will continue to try and Android methods and will start by
trying fastboot.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210701132612.7559-3-trini@konsulko.com
This include file is only used by ti_omap5_common.h. Further, the move
is towards using the generic distro boot framework and not this set of
macros. Start by moving all of the contents in directly to where they
are used.
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210701132612.7559-2-trini@konsulko.com
Remove the environment support for various legacy boot methods. With
this, we will now default to booting any distribution that follows the
generic distro boot framework and no longer attempt to boot various
legacy (to this SoC) scripts/etc.
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210701132612.7559-1-trini@konsulko.com
SPL is really tight on space, so decrease a little memory that we
allocate in order to fix boot hang.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>
Link: https://lore.kernel.org/r/20210626134258.601331-1-aford173@gmail.com
secureworld_exit() is only used in one file, so make it static
to that file and remove it from sys_proto.h. This
may help with some further optimization in the future.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210625192308.277136-3-aford173@gmail.com
try_unlock_memory() is only used in one file, so make it static
in that file,remove it from the sys_proto header file, and relocate
it into the #ifdef section that call it. This will make it only built
under the conditions when it is called, and it may help with some
further optimization in the future.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210625192308.277136-2-aford173@gmail.com
The AM3517 uses SYS_MALLOC_F_LEN of size 0x3000, but the rest of
the OMAP3 boards from LogicPD / BeaconEmbedded use 0x4000, but
they don't boot SPL.
Reduce the malloc size to restore booting.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210625185717.243211-1-aford173@gmail.com
The `struct udevice *` reference is needed for either of the
K3_LOAD_SYSFW, K3_AM64_DDRSS config guards. Adding the missing
K3_AM64_DDRSS guard.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210624171614.14244-1-g-tammana@ti.com
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems
that are present on the K3 AM65x SoCs. The three ICSSGs are identical
to each other for the most part, with the ICSSG2 supporting slightly
enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance
is represented by a PRUSS subsystem node. These nodes are enabled by
default.
DT nodes are fetch from Linux 5.13 Kernel.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210622063431.3151-5-lokeshvutla@ti.com
So far all the u-boot specific properties for both r5 and a53 are
placed in k3-am654-base-board-u-boot.dtsi. But there are few a53
nodes that should be updated but doesn't belong to r5. So create a
separate r5 specific u-boot dtsi.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210622063431.3151-4-lokeshvutla@ti.com
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem on AM65x SR1.0 contains two primary PRU cores and two new
auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised
ICSSG IP that is based off the subsequent IP revision used on J721E
SoCs. This IP instance has two new custom auxiliary PRU cores called
Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs.
Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than
a PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, while the Tx_PRU cores is
normally used to control the TX L2 FIFO if enabled in Ethernet
applications. Both can also be used to run independent applications.
The RTU and Tx_PRU cores though share the same Data RAMs as the PRU
cores, so the memories have to be partitioned carefully between different
applications. The new cores also support a new sub-module called Task
Manager to support two different context thread executions.
The driver currently supports the AM65xx SoC
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210622063431.3151-3-lokeshvutla@ti.com
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the AM654x family. Each SoC can have
one or more PRUSS instances that may or may not be identical.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.
Add support for pruss driver. Currently am654x family
is supported.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210622063431.3151-2-lokeshvutla@ti.com
The final 128KB in SRAM is reserved by default for DMSC-lite code and
secure proxy communication buffer. The memory region used for DMSC-lite
code can be optionally freed up by secure firmware API[1]. However, the
buffer for secure proxy communication is not configurable. This default
hardware configuration is unique for AM64.
Therefore, indicate the area reserved for DMSC-lite code and secure proxy
communication buffer in the oc_sram device tree node.
[1] - http://downloads.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#triggering-security-handover
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210616163821.20457-3-a-govindraju@ti.com
Earlier, the region 0x701c0000 to 0x701dffff was firewalled off because of
a bug in SYSFW. In the v2021.05 release of SYSFW this bug has been fixed
and this region can now be used for other allocations.
Therefore, move TF-A's load address to 0x701c0000 and update its location
in the device tree node. Also, increase the size allocated for TF-A to
account for future expansions.
Fixes: defd62ca13 ("arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210616163821.20457-2-a-govindraju@ti.com
Remove the environment support for various legacy boot methods. With
this, we will now default to booting any distribution that follows the
generic distro boot framework and no longer attempt to boot various
legacy (to this SoC) scripts/etc.
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210610230147.22475-1-trini@konsulko.com
RTC second scratch register[32-bit]:
-zero byte hold boot count value
-first byte hold update available state
-second byte hold version
-third byte hold magic number
Signed-off-by: Gireesh Hiremath <Gireesh.Hiremath@in.bosch.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210611161350.2141-17-Gireesh.Hiremath@in.bosch.com
Gbp-Pq: Topic apertis/guardian
Gbp-Pq: Name am335x-guardian-software-update-available-status-is-store.patch
