I would like to help maintaining the imx8mn_var_som symphony board.
Add myself to MAINTAINERS.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
With DM enabled, there is no need for board code to initialize
the Ethernet interfaces.
The RTL8211FDI Ethernet PHYs have 25MHz oscillator, so there is no
need to enable the RGMII TX clk output.
Also, there is no need for describing the deprecated phy-reset FEC
properties, nor passing reset properties to the EQOS interface in
u-boot.dtsi.
Remove all these unneeded pieces.
Tested both Ethernet interfaces after these changes.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
I would like to help maintaining the imx8mp_evk board.
Add myself to MAINTAINERS.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Peng Fan <peng.fan@nxp.com>
Currently, the imx8mp_evk uses the non-DM code to initialize the PMIC.
Convert to DM_PMIC, which is the recommended way to access the PMIC.
While at it, fix multi-line comments style.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Add a common board_interface_eth_init() called by the DWC MAC driver to
setup the MAC <-> PHY interface according to the PHY mode obtained from
DT.
Remove the board-side configuration in the i.MX93 EVK files.
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Sync the devicetree files used in the kernel for the imx8mm-phyboard-polis
with the corresponding devicetree files in U-Boot.
Replaced phycore-imx8mm.dts with kernel dts imx8mm-phyboard-polis-rdk.dts
Synced with kernel 6.5.0-rc1 commit
e752a4f9589c (arm64: dts: freescale: imx8mm-phyboard: Add I2C4 pinmuxing)
Signed-off-by: Cem Tenruh <c.tenruh@phytec.de>
Commit 0aea5dda29 ("ARM: dts: imx7d-sdb-u-boot: Fix usdhc1 UHS
operation") did a temporary workaround by addng the usdhc1 fix
inside the -u-boot.dtsi file.
The imx7d-sdb.dts from kernel 6.5-rc1 contains the proper UHS
fix, so sync the devicetree tree and remove the previous fix
from -u-boot.dtsi.
Also, adjust the PMIC node name inside pmic_get() to match
the devicetree update.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Add support for the Polyhex Debix Model A SBC board.
It is an industrial grade single board computer based on
NXP's i.MX 8M Plus.
Currently supported interfaces are:
- Serial console
- Micro SD
- eQOS and FEC Ethernet
imx8mp-debix-model-a.dts is taken from Linux 6.3.
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
In case of A/B update systems there should be an option to load the same
binary/binaries to different location and they should work.
Before this patch boot.bin with U-Boot SPL can be added to whatever 32k
offset in SPI and SPL finds u-boot.itb at CONFIG_SYS_SPI_U_BOOT_OFFS
offset. In case of A/B update systems that means that SPL is at different
locations but it still points to the same u-boot.itb which is not correct.
That's why include multiboot value to offset calculation to be able to
point to image from the same base.
It doesn't affect any current system which starts from 0 offset.
This patch also change Kria defconfig which uses A/B setup. Partition
A starts at multiboot 64, partition B at multiboot 496.
And also print message about used SPI offset which is useful for all cases.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/93903a53ad9358ae69991558b787f574797effbe.1699619666.git.michal.simek@amd.com
Enable the initial kria SOM specific configurations like pinctrl,
pinconf etc. Also add the environment file.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20231109042407.6123-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Later versions of Colibri iMX7D V1.1B modules use a "new" SoC fusing. The
difference lies in whether we enable the boot ROM to use the eMMC reset
signal. Depending on the SoC fuse, the boot ROM configures this pin as a
GPIO output to drive the reset signal. Our eMMC vs NAND detection
currently only sets that signal to a GPIO without explicitly setting any
direction. Previously, by default, it was set as an input. As the boot ROM
now configures it as an output, we receive a value of zero instead of one,
indicating the absence of the pull-up on eMMC modules.
To fix this, set the SION bit, allowing the reading back of the value
even if it is configured as an output by the boot ROM. It's important to
note that with the new SoC fusing, we now read back what the boot ROM
drives rather than the real value caused by the pull-up resistor. However,
if it were ever driven low, the eMMC would permanently be reset.
In addition, remove hard-coded variant in the eMMC build case as since the
commit 0c39564d02 ("toradex: colibri_imx7: Enable nand/emmc detection
and set boot variant") will anyways always get overridden by the detection
routing in board code.
Fixes: 0c39564d ("toradex: colibri_imx7: Enable nand/emmc detection and set boot variant")
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Initially investigating a Linux network issue causing a lot of drop and
poor network performances on a custom system based on a TQMA6A module
(based on an iMX6Q), [1st link below].
I eventually correlated my observations with a contention at the NIC
level when in concurrency with the graphics pipeline. Troubleshooting
this in the kernel lead to disabling DMA bursts accesses made by the IPU
in order to avoid triggering the QoS at the interconnect level, reducing
from 50 to 10% the drop rate on eth0, [2nd link below]. The solution
worked on my setup but not on others, which still suffered from
abnormally high drop rates even with this "fix".
After looking a while into TQ Systems BSP I figured out a number of
differences in recent U-Boot out-of-tree patches they had in their
repository [3rd link]. Parsing the differences one after the other lead
me to this final solution.
The reset pad of the DDR controller was apparently misconfigured, Bit
18-19 picturing the "DDR select field". The current value b11 is
reserved. The only defined value as of version 6 of the iMX6Q manual was
b00 "DDR3 and LPDDR2 mode". In practice no register difference has been
spotted after changing this configuration but all issues tracked thus
far just vanished. All previous fixes have been proven irrelevant. Just
clearing this field solved all our network issues and the drop rate as
measured by iperf3 felt back to 0%.
Link: https://lore.kernel.org/netdev/20231012193410.3d1812cf@xps-13/
Link: https://lists.freedesktop.org/archives/dri-devel/2023-October/428251.html
Link: 15eb6abbef
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
GW73xx-F board revision switched back to the original PCIe switch due to
part availability.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
- StarFive: Add StarFive watchdog driver
- VisionFive2: Support device tree overlay for VisionFive2 board
- Andes: Fix PLIC-SW setting
- RISC-V: Fix NVMe support by implying NVME_PCI for QEMU
- RISC-V: Fix binman for 64 bit format load address
The OrangePi Zero 3 is a small development board featuring the Allwinner
H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
connector and two USB sockets.
The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
which was recently added to U-Boot.
Add a defconfig file selecting the right drivers and DRAM options.
Since the .dts file was synced from the Linux kernel repo already, we
just need to add one line to the Makefile to actually build the .dtb.
The DRAM parameters were derived from the values found in the BSP DRAM
drivers on the SPI NOR flash.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Tested-by: Bob McChesney <bob@electricworry.net>
Tested-by: Stephen Graf <stephen.graf@gmail.com>
CONFIG_NVME=y without CONFIG_NVME_PCI=y does not provide working NVMe
support. Instead of implying CONFIG_NVME we must imply CONFIG_NVME_PCI
which will select CONFIG_NVME.
Fixes: e64db0d92e ("riscv: qemu: Enable e1000 and nvme support")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
To quote the author:
The show_board_info() function was adjusted to weak so that it could be
entirely replaced with a board-specific implementation.
The intended way for boards to provide their own information is via a
sysinfo driver. But currently there is no way to show anything other
than the model name.
This series adds support for showing a few more items, in a way that is
easy for boards to extend.
Since there is already a weak checkboard() function, we don't need to
have two levels of weak function here. So this series drops the weak
attribute from show_board_info()
Existing boards will see a slight change in output, in that the model
name will appear first, before any custom output. If that is a problem,
then the solution is to implement a sysinfo driver for the board.
Create a sysinfo driver to avoid needing a custom checkboard()
function. With this the following information is printed when booting
from coreboot under QEMU:
Model: Standard PC (i440FX + PIIX, 1996)
Manufacturer: QEMU
Prior-stage version: 4.21-885-g2a87ef1eca56
Prior-stage date: 11/11/2023
Signed-off-by: Simon Glass <sjg@chromium.org>
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Make all the checkboard() functions call the new tdx_checkboard() so
that the same information is displayed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Boards can use a sysinfo driver if a particular model name is needed.
Update this board to use checkboard() directly, rather than having a
weak function laid on top of a weak function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
This enables UFS support for QEMU RISC-V 'virt' machine.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There is a couple of issues related to SYS_CONFIG_NAME config in
axy17lte Kconfig.
1. The global SYS_CONFIG_NAME in axy17lte Kconfig overrides
SYS_CONFIG_NAME for all boards specified after this line in
arch/arm/mach-exynos/Kconfig:
source "board/samsung/axy17lte/Kconfig"
Right now it's the last 'source' line there, so the issue is not
reproducible. But once some board is moved or added after this line
the next build error will happen:
GEN include/autoconf.mk.dep
In file included from ./include/common.h:16:
include/config.h:3:10: fatal error: configs/exynos78x0-common.h.h:
No such file or directory
3 | #include <configs/exynos78x0-common.h.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
That's happening because axy17lte Kconfig defines SYS_CONFIG_NAME
option in global namespace (not guarded with any "if TARGET_..."), so
it basically rewrites the correct SYS_CONFIG_NAME defined in the
hypothetical boards which might appear after axy17lte in mach-exynos
Kconfig.
2. Another side of the issue is that SYS_CONFIG_NAME is defined
incorrectly in axy17lte Kconfig:
config SYS_CONFIG_NAME
default "exynos78x0-common.h"
The .h extension should not have been specified there. It's leading
to a build error, as the generated include file has a double '.h'
extension.
3. Each target in axy17lte/Kconfig defines its own SYS_CONFIG_NAME. But
all of those in fact incorrect, as corresponding
include/configs/<CONFIG_SYS_CONFIG_NAME>.h header files don't exist.
4. The global SYS_CONFIG_NAME pretty much repeats the help description
from arch/Kconfig and doc/README.kconfig.
Corresponding defconfig files (a*y17lte_defconfig) fix above issues by
overriding SYS_CONFIG_NAME and correctly setting it to
"exynos78x0-common".
Fix all mentioned issues by removing the incorrect global
SYS_CONFIG_NAME and instead specifying it (correctly) in SYS_CONFIG_NAME
options for each target instead.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Fixes: 3e2095e960 ("board: samsung: add support for Galaxy A series of 2017 (a5y17lte)")
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
If CONFIG_SYS_SKIP_UART_INIT is enabled, calculate the
current baud rate and update the "console" environment
variable.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
Draco is a family of 3 boards: thuban, rastaban & etamin. Rename all
targets of the family adding the draco- prefix to increase readibility
and simplify future commits about concerning all boards of the family.
The name draco was initially used for the first target. It's deprecated
since a 2nd target was introduced. Unfortunately the draco target was
copied to the thuban target instead to be renamed. Remove it to save
unnecessary maintenance effort.
Signed-off-by: Enrico Leto <enrico.leto@siemens.com>
BeagleBoard.org BeagleBone AI-64 is an open source hardware single
board computer based on the Texas Instruments TDA4VM SoC featuring
dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x
floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors,
2x 6-core Programmable Real-Time Unit and Industrial Communication
SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB
DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane
CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and
BeagleBone expansion headers.
This board family can be indentified by the BBONEAI-64-B0 in the
at24 eeprom:
[aa 55 33 ee 01 37 00 10 2e 00 42 42 4f 4e 45 41 |.U3..7....BBONEA|]
[49 2d 36 34 2d 42 30 2d 00 00 42 30 30 30 37 38 |I-64-B0-..B00078|]
Baseline of the devicetree is from v6.6-rc1
https://beagleboard.org/ai-64https://git.beagleboard.org/beagleboard/beaglebone-ai-64
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
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>
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>
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>
