| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Acked-by: Jaehoon Chung <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The usbtty functionality is not currently used on these two platforms,
disable it.
Cc: Lokesh Vutla <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]> (maintainer:J721E BOARD)
Signed-off-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
<configs/ti_omap5_common.h>
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Tested-by: Derald D. Woods <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
secure_unlock_mem() is only used in one file, so make it static
in that file.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable PRUSS remoteproc driver for AM65
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Murali Karicheri <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
communication
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Acked-by: Suman Anna <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: defd62ca137b ("arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size")
Signed-off-by: Aswath Govindraju <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Reviewed-by: Suman Anna <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
add support to direct memory access of hardware peripherals registers
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
include bootcount nvmem support
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
scracth register
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 <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Gbp-Pq: Topic apertis/guardian
Gbp-Pq: Name am335x-guardian-software-update-available-status-is-store.patch
|
|
- Enable lcd controller
- Display splash screen
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
update panel driver hx8238
fix build bug
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
-Enable configuration for display driver
-Disable support for SPL GPIO, CMD LED & SPL GPIO
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable backlight, set brightness value and dimming frequency
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
read boot mode gpio and set the swi status
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
- disable support for spl command
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
- set boot delay to zero, to increase boot speed
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
- remove redundant headers and boot modes from board file
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
autoload: if set to "no" then rarpb, bootp or dhcp commands will
just perform a configuration lookup from the BOOTP / DHCP server,
but not try to load any image using TFTP
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
pinmux update for guardian board
- control ASP Board Power: GPIO, on/off ASP Board Power
- control Coincell Voltage Measurement: GPIO, enable/disable
ADC measurements
- powerOff Device GPIO-PowerOff, cut the PMIC supply
Signed-off-by: Moses Christopher <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
- Add mtest, meminfo commands
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Set tftp_load_addr to 0x82000000 in MEM_LAYOUT_ENV_SETTINGS
Signed-off-by: Moses Christopher <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
- Trigger fastmap automatically
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
- Add mem-guardian.h derived from am33xx/mem.h
* Add GPMC config values optimized for Bosch Guardian Board
* NAND Chip used by Bosch Guardian Board is Micron MT29F4G08ABBFA
Signed-off-by: Moses Christopher <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable TI clock driver support for guardian board
Signed-off-by: Gireesh Hiremath <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This is a revert of a recent logic change in setup_zimage(). We do
actually need to install this information always. Change it to install
from the Coreboot tables if available, else the normal source.
Fixes: e7bae8283fe ("x86: Allow installing an e820 when booting from coreboot")
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
With the new 2021.04 we have a new version of Chromium OS boot, which
supports sandbox, coral and coral-on-coreboot. Add documentation for
this.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
With of-platdata-inst we want to set up a reference to each devices'
parent device, if there is one. If we find that the device has a parent
(i.e. is not a root node) but it is not in the list of devices being
written, then we cannot create the reference.
Report an error in this case, since it indicates that the parent node
is either missing a compatible string, is disabled, or perhaps does not
have any properties because it was not tagged for SPL.
Signed-off-by: Simon Glass <[email protected]>
|
|
All the x86 devicetree files are built at once, whichever board is
actually being built. If coreboot is the target build, CONFIG_ROM_SIZE
is not defined and samus cannot build Chromium OS verified boot. Add
this condition to avoid errors about CONFIG_ROM_SIZE being missing.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
Add information about memory usage when U-Boot is started from coreboot.
This is useful when debugging. Also, since coreboot takes a chunk of
memory in the middle of SDRAM for use by PCI devices, it can help avoid
overwriting this with a loaded kernel by accident.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Use VENDOR_COREBOOT instead of TARGET_COREBOOT so we can have multiple
coreboot boards, sharing options. Only SYS_CONFIG_NAME needs to be
defined TARGET_COREBOOT.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Add a function comment for get_coreboot_info() and a declaration for
cb_get_sysinfo(), since this may be called from elsewhere.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Set up coral so that it can boot from coreboot, even though it is a
bare-metal build. This helps with testing since the same image can be used
in both cases.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
The BIOS version may not be present, e.g. on a Chrome OS build. Add the
BIOS date as well, so we get some sort of indication of coreboot's
vintage.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
A recent change to disable cache setup when booting from coreboot
assumed that this has been done by SPL. The result is that for the
coreboot board, the cache is disabled (in start.S) and never
re-enabled.
If the cache was turned off, as it is on boards without SPL, we should
turn it back on. Add this new condition.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
These constants conflict with error codes returned by the MP
implementation when something is wrong. In particular, mp_first_cpu()
returns MP_SELECT_BSP when running without multiprocessing enabled.
Since this is -2, it is interpreted as an error by callers, which
expect a positive CPU number for the first CPU.
Correct this by using a different range for the pre-defined CPU
numbers, above zero and out of the range of possible CPU values. For
now it is safe to assume there are no more than 64K CPUs.
This fixes the 'mtrr' command when CONFIG_SMP is not enabled.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
