net: ti: am65-cpsw-nuss: Prepare to support non primary ext port
CPSW NUSS IP on K3 SoCs can have more than one external port (upto 8)
Therefore increase AM65_CPSW_CPSWNU_MAX_PORTS to 9 (8 ext + 1 Root port)
as preparation to allow any one of the 8 ports to be used as ethernet
interface in U-Boot.
soc: ti: k3-navss-ringacc: Remove unused ring modes
With AM64x supporting only K3_NAV_RINGACC_RING_MODE_RING or the exposed
ring mode, all other K3 SoCs have also been moved to this common
baseline. Therefore drop other modes such as
K3_NAV_RINGACC_RING_MODE_MESSAGE (and proxy) to save on SPL footprint.
There is a saving of ~800 bytes with this change for am65x_evm_r5_defconfig.
soc: ti: k3-navss-ringacc: Add AM64 ringacc support
AM64 dual mode rings are modeled as pair of Rings objects which has common
configuration and memory buffer, but separate real-time control register
sets for each direction mem2dev (forward) and dev2mem (reverse).
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Lokesh Vutla [Thu, 6 May 2021 11:14:59 +0000 (16:44 +0530)]
arm: dts: am642-sk: Add initial sk dts
AM642 StarterKit (SK) board is a low cost, small form factor board
designed for TI’s AM642 SoC. It supports the following interfaces:
* 2 GB LPDDR4 RAM
* x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode
* x1 USB 3.0 Type-A port
* x1 UHS-1 capable µSD card slot
* 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837
* 512 Mbit OSPI flash
* x2 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin Raspberry Pi compatible GPIO header
* 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO)
* 54-pin header for Programmable Realtime Unit (PRU) IO pins
* Interface for remote automation. Includes:
* power measurement and reset control
* boot mode change
Lokesh Vutla [Thu, 6 May 2021 11:14:55 +0000 (16:44 +0530)]
include: configs: Update env for selecting right dtb
Now that single defconfig can be used for booting AM64 EVM and SK,
default device tree will not work for selecting dtb for kernel.
Update the env to select right dtb based on eeprom.
Lokesh Vutla [Thu, 6 May 2021 11:14:49 +0000 (16:44 +0530)]
board: ti: am64x: Add support for reading eeprom data
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot.
Dave Gerlach [Tue, 4 May 2021 23:00:53 +0000 (18:00 -0500)]
arm: mach-k3: am642: Add support for triggering ddr init from SPL
In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().
Dave Gerlach [Tue, 11 May 2021 15:22:12 +0000 (10:22 -0500)]
ram: k3-ddrss: Introduce support for AM642 SoCs
Introduce support for the AM64 DDRSS controller which uses the 16bit
variation of the controller. This controller shares much functionality
with the existing J721e support, so this patch introduces only the new
code needed for am64 specific support from "_16bit_" files with headers
under "16bit/" include path/.
Also add a CONFIG_K3_AM64_DDRSS option to the choice required for use
with CONFIG_K3_DDRSS to allow selecting AM64 support.
Dave Gerlach [Tue, 11 May 2021 15:22:11 +0000 (10:22 -0500)]
ram: k3-ddrss: Introduce common driver with J7 SoC support
Introduce a new version of the ddr driver which has the ability to
support different variations of the controller. Also introduce support
for the 32bit variation of the controller which is what was already
supported by the previous version used for J721e and J7200.
Create a new CONFIG_K3_DDRSS option to select the common parts of the
k3-ddrss driver. Also introduce a choice that depends on the top level
option to select CONFIG_K3_J721E_DDRSS for j721e support, and update
corresponding Kconfig as required.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Fix the indentation for certain macros to be consistent with the other
macros in the file, as the existing indentation does not make sense in
many places.
Dave Gerlach [Fri, 23 Apr 2021 16:27:45 +0000 (11:27 -0500)]
arm: dts: k3-am642: Add initial support for EVM
The AM642 EValuation Module (EVM) is a board that provides access to
various peripherals available on the AM642 SoC, such as PCIe, USB 2.0,
CPSW Ethernet, ADC, and more.
Dave Gerlach [Fri, 23 Apr 2021 16:27:44 +0000 (11:27 -0500)]
arm: dts: ti: Add Support for AM642 SoC
The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.
Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
peripherals.
* Centralized System Controller for Security, Power, and Resource
Management (DMSC).
See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
Introduce basic support for the AM642 SoC to enable SD/MMC boot.
Introduce a limited set of MAIN domain peripherals under cbass_main and
a set of MCU domain peripherals under cbass_mcu.
Dave Gerlach [Fri, 23 Apr 2021 16:27:43 +0000 (11:27 -0500)]
dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64
Add pinctrl macros for AM64 SoC. These macro definitions are similar to
that of previous platforms, but adding new definitions to avoid any
naming confusions in the soc dts files.
Dave Gerlach [Fri, 23 Apr 2021 16:27:41 +0000 (11:27 -0500)]
mailbox: k3-sec-proxy: Extend valid thread IDs
AM64x uses a different thread mapping that existing K3 SoCs, so update
the valid thread ID list to include those used for AM64x.
Also remove the comment identifying the purpose of each thread ID. The
purpose of the thread ID is specified when describing the threads in the
device tree and the same ID can mean different things on different SoCs,
so the comment is not useful.
Change the memory attributes for the DDR regions used by the remote
processors on AM65x so that the cores can see and execute the proper code.
A separate table based on the previous K3 SoCs is introduced since the
number of remote processors and their DDR usage is different between the
SoC families.
Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Suman Anna [Fri, 23 Apr 2021 16:27:38 +0000 (11:27 -0500)]
arm: mach-k3: am642: Shut down R5 core after ATF startup on A53
The AM642 SoCs use the Main R5FSS0 as a boot processor, and runs
the R5 SPL that performs the initialization of the System Controller
processor and starting the Arm Trusted Firmware (ATF) on the Arm
Cortex A53 cluster. The Core0 serves as this boot processor and is
parked in WFE after all the initialization. Core1 does not directly
participate in the boot flow, and is simply parked in a WFI.
Power down these R5 cores (and the associated RTI timer resources
that were indirectly powered up) after starting up ATF on A53 by
using the appropriate SYSFW API in release_resources_for_core_shutdown().
This allows these Main R5F cores to be further controlled from the
A53 to run regular applications.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Dave Gerlach [Fri, 23 Apr 2021 16:27:36 +0000 (11:27 -0500)]
arm: mach-k3: am642: Load SYSFW binary and config from boot media
Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM642 early initialization sequence. Also
make use of existing logic to detect if ROM has already loaded sysfw
and avoided attempting to reload and instead just prepare to use already
running firmware.
While at it also initialize the MAIN_UART1 pinmux as it is used by SYSFW
to print diagnostic messages.
Dave Gerlach [Fri, 23 Apr 2021 16:27:35 +0000 (11:27 -0500)]
arm: mach-k3: am642: Store boot info from ROM
For AM642, ROM supports loading system firmware directly
from boot image. ROM passes information about the number of
images that are loaded to bootloader at a specific address
that is temporary. Add support for storing this information
somewhere permanent before it gets corrupted.
arm: mach-k3: am642: Add support for boot device detection
AM642 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.
Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Dave Gerlach [Fri, 23 Apr 2021 16:27:32 +0000 (11:27 -0500)]
arm: mach-k3: Add basic support for AM642 SoC definition
The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.
Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
peripherals.
* Centralized System Controller for Security, Power, and Resource
Management (DMSC).
See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
As pointed by [1] and [2], the reverted patch made every DT 'reg'
property translatable. What the patch was trying to fix was fixed in a
different way from previously submitted patches which instead of
correcting the generic address translation function fixed the issue with
appropriate platform code.
Dario Binacchi [Sat, 1 May 2021 15:05:25 +0000 (17:05 +0200)]
clk: ti: am3-dpll: use custom API for memory access
Using the custom TI functions required not only replacing common memory
access functions but also rewriting the routines used to set bypass and
lock states. As for readl() and writel(), they also required the address
of the register to be accessed, a parameter that is hidden by the TI clk
module.
Dario Binacchi [Sat, 1 May 2021 15:05:23 +0000 (17:05 +0200)]
clk: ti: change clk_ti_latch() signature
The clock access functions exported by the clk header use the
struct clk_ti_reg parameter to get the address of the register. This
must also apply to clk_ti_latch(). Changes to TI's clk-mux and
clk-divider drivers prevented the patch from generating compile errors.
Dario Binacchi [Sat, 1 May 2021 15:05:22 +0000 (17:05 +0200)]
clk: ti: add custom API for memory access
As pointed by [1] and [2], commit d64b9cdcd4 ("fdt: translate address if #size-cells = <0>") is wrong:
- It makes every 'reg' DT property translatable. It changes the address
translation so that for an I2C 'reg' address you'll get back as reg
the I2C controller address + reg value.
- The quirk must be fixed with platform code.
The clk_ti_get_reg_addr() is the platform code able to make the correct
address translation for the AM33xx clocks registers. Its implementation
was inspired by the Linux Kernel code.
Tom Rini [Thu, 6 May 2021 15:00:07 +0000 (11:00 -0400)]
Merge branch '2021-05-06-misc-updates'
- Allow for boards to update bootargs before booting the OS (helpful in
some forms of secure boot).
- Enhance GPT write support.
- gpio-sysinfo updates
- Allow env to be appended from dtb
Signed-off-by: Green Wan <green.wan@sifive.com> Reviewed-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
Green Wan [Mon, 3 May 2021 06:23:04 +0000 (23:23 -0700)]
riscv: cpu: Add callback to init each core
Add a callback harts_early_init() to start.S to allow different riscv
hart perform setup code for each hart as early as possible. Since all
the harts enter the callback, they must be able to run the same
setup.
Signed-off-by: Green Wan <green.wan@sifive.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Farhan Ali [Fri, 26 Feb 2021 18:17:33 +0000 (10:17 -0800)]
cmd: gpt: Add option to write GPT partitions to environment variable
This change would enhance the existing 'gpt read' command to allow
(optionally) writing of the read GPT partitions to an environment
variable in the UBOOT partitions layout format. This would allow users
to easily change the overall partition settings by editing said variable
and then using the variable in the 'gpt write' and 'gpt verify' commands.
Signed-off-by: Farhan Ali <farhan.ali@broadcom.com> Cc: Simon Glass <sjg@chromium.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Corneliu Doban <cdoban@broadcom.com> Cc: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
Check that a variable defined in /config/environment is found in the
run-time environment, and that clearing fdt_env_path from within that
node works.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
[trini: Conditionalize the test being linked in] Signed-off-by: Tom Rini <trini@konsulko.com>
env: allow environment to be amended from control dtb
It can be useful to use the same U-Boot binary for multiple purposes,
say the normal one, one for developers that allow breaking into the
U-Boot shell, and one for use during bootstrapping which runs a
special-purpose bootcmd. Or one can have several board variants that
can share almost all boot logic, but just needs a few tweaks in the
variables used by the boot script.
To that end, allow the control dtb to contain a /config/enviroment
node (or whatever one puts in fdt_env_path variable), whose
property/value pairs are used to update the run-time environment after
it has been loaded from its persistent location.
The indirection via fdt_env_path is for maximum flexibility - for
example, should the user wish (or board logic dictate) that the values
in the DTB should no longer be applied, one simply needs to delete the
fdt_env_path variable; that can even be done automatically by
including a
fdt_env_path = "";
property in the DTB node.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Sean Anderson [Tue, 20 Apr 2021 14:50:56 +0000 (10:50 -0400)]
sysinfo: Require that sysinfo_detect be called before other methods
This has the uclass enforce calling detect() before other methods. This
allows drivers to cache information in detect() and perform (cheaper)
retrieval in the other accessors. This also modifies the only instance
where this sequencing was not followed.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 20 Apr 2021 14:50:55 +0000 (10:50 -0400)]
sysinfo: Use global sysinfo IDs for existing sysinfo drivers
Since 07c9e683a4 ("smbios: Allow a few values to come from sysinfo")
there are common global sysinfo IDs. This patch moved existing IDs above
SYSINFO_ID_USER.
Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 20 Apr 2021 14:50:54 +0000 (10:50 -0400)]
dm: gpio: Fix gpio_get_list_count failing with livetree
of_parse_phandle_with_args (called by dev_read_phandle_with_args) does not
support getting the length of a phandle list by using the index -1.
Instead, use dev_count_phandle_with_args which supports exactly this
use-case.
Fixes: 8558217153 ("gpio: Convert to use APIs which support live DT") Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Thu, 29 Apr 2021 15:31:06 +0000 (11:31 -0400)]
Merge tag 'xilinx-for-v2021.07-rc2' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2021.07-rc2
xilinx:
- Enable saving variables based on bootmode
- Cleanup usb dfu setup and wire it up with usb bootmode
- Fix bootscript address logic
- Remove GD references (spi, Versal)
- Enable capsule update
- Add base support for Marvell OcteonTX2 CN9130 CRB (mostly done
by Kostya)
- Sync Armada 3k/7k/8k SERDES code with Marvell version (misc Marvell
authors)
- pci-aardvark: Fix processing PIO transfers (Pali)
projects / u-boot.git / log
