The phyCORE-AM62x and phyCORE-AM64x R5 SPL detects the populated DDR
size from the SoM EEPROM and falls back to 2 GB if detection fails. For
boards without a populated EEPROM or if no detection needed, the detection
can be bypassed via CONFIG_PHYCORE_AM6{2,4}X_RAM_SIZE_FIX and one of
the CONFIG_PHYCORE_AM6{2,4}X_RAM_SIZE_<size> choices.
Add a "DDR RAM Size" section to both board docs describing this
behaviour and listing the available size options (1/2/4 GB for AM62x,
1/2 GB for AM64x).
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Add two short sections to the common K3 phyCORE docs.
Describe the default boot flow and its deprecated version.
And write down the use of the watchdog.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
A handful of small inaccuracies had crept into the phyCORE-AM6x docs.
Mostly typos and formatting Issues. Fix them. While at it, update the
am62a board to use the correct product link.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Daniel Golle <daniel@makrotopia.org> says:
This series adds dm-verity support to U-Boot's FIT image infrastructure.
It is the first logical subset of the larger OpenWrt boot method series
posted as an RFC in February 2026 [1], extracted here for independent
review and merging.
OpenWrt's firmware model embeds a read-only squashfs or erofs root
filesystem directly inside a uImage.FIT container as a FILESYSTEM-type
loadable FIT image. At boot the kernel maps this sub-image directly from
the underlying block device via the fitblk driver (/dev/fit0, /dev/fit1,
...), the goal is that the bootloader never even copies it to RAM.
dm-verity enables the kernel to verify the integrity of those mapped
filesystems at read time, with a Merkle hash tree stored contiguously in
the same sub-image just after the data. Two kernel command-line
parameters are required:
dm-mod.create= -- the device-mapper target table for the verity device
dm-mod.waitfor= -- a comma-separated list of block devices to wait for
before dm-init sets up the targets (needed when fitblk
probes late, e.g. because it depends on NVMEM
calibration data)
The FIT dm-verity node schema was upstreamed into the flat-image-tree
specification [2], which this implementation tries to follow exactly.
The runtime feature is guarded behind CONFIG_FIT_VERITY. If not
enabled the resulting binary size remains unchanged. If enabled the
binary size increases by about 3kB.
[1] previous submissions:
RFC: https://www.mail-archive.com/u-boot@lists.denx.de/msg565945.html
v1: https://www.mail-archive.com/u-boot@lists.denx.de/msg569472.html
v2: https://www.mail-archive.com/u-boot@lists.denx.de/msg570599.html
v3: https://www.mail-archive.com/u-boot@lists.denx.de/msg573223.html
v4: https://www.mail-archive.com/u-boot@lists.denx.de/msg574000.html
[2] flat-image-tree dm-verity node spec:
795fd5fd7f
Link: https://lore.kernel.org/r/cover.1778887196.git.daniel@makrotopia.org
Add documentation for CONFIG_FIT_VERITY which allows U-Boot to
construct dm-mod.create= and dm-mod.waitfor= kernel command-line
parameters from dm-verity metadata embedded in FIT filesystem
sub-images.
The new document covers the relationship between FIT loadable indices
and the /dev/fitN block devices that the Linux uImage.FIT block driver
creates, provides a complete .its example with a dm-verity-protected
SquashFS root filesystem, describes all required and optional dm-verity
subnode properties and explains how mkimage generates the verity
metadata automatically.
dm-verity is only supported for external-data FIT images (mkimage -E);
mkimage aborts with an error if the flag is omitted.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Environment callbacks can already be configured from Kconfig with
CONFIG_ENV_CALLBACK_LIST_STATIC, but static environment flags still
require board headers to define CFG_ENV_FLAGS_LIST_STATIC.
Add CONFIG_ENV_FLAGS_LIST_STATIC and use it as the only board-provided
static environment flags list. Convert the remaining default-config users
from CFG_ENV_FLAGS_LIST_STATIC to defconfig settings and drop the legacy
header macro from ENV_FLAGS_LIST_STATIC.
Move the environment flags format documentation out of README and into
the developer environment documentation. Include the format in the
Kconfig help as well.
This lets boards configure writeable-list policy and type validation
from defconfig without adding a config header solely for env flags.
This preserves the behavior of default configs. Header-only cases that
were inactive in upstream defconfigs are not converted into defconfig
entries: iot2050 can add its list when enabling ENV_WRITEABLE_LIST, and
smegw01 can add mmcdev:dw support if the unlocked SYS_BOOT_LOCKED=n
configuration is needed.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Walter Schweizer <walter.schweizer@siemens.com>
Our official domain is now u-boot-project.org, so update all in-tree
references to use the correct domain.
Reviewed-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The option is only available when CONFIG_SYSRESET_QCOM_PSCI is enabled,
so let's make that explicit in the boot cmd documentation.
Due to the implementation in drivers/sysreset/sysreset-uclass.c
do_reset() function, all options to the reset command are passed to all
sysreset drivers' sysreset_ops.request_arg callback (including -w) which
is only available when CONFIG_SYSRESET_CMD_RESET_ARGS=y. -w, however,
works also without this option.
Fixes: ef06c5d76f ("cmd: boot: Add '-edl' option to reset command documentation")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
"Do warm WARM" doesn't mean anything, I'm assuming the intent was to say
"Do WARM reset" so reword.
Fixes: 34e452dd02 ("doc: usage: Group all shell command docs into cmd/ sub-directory")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add instructions on how to use U-Boot to save
DDR training data to NVM and explain the saving
process.
Signed-off-by: Simona Toaca <simona.toaca@nxp.com>
Janne Grunau <j@jannau.net> says:
The Linux device trees for Apple silicon devices cover now most of the
hardware as u-boot's internal device trees for M1 devices. Linux has in
addition device trees M2 and M1 and M2 Pro/Max/Ultra devices which were
never added in u-boot.
The most common use case for u-boot on Apple silicon devices does not
use DTBs from u-boot but passes runtime modified device trees from an
earlier boot loader (m1n1).
This change regresses support for the SPI on M1 and M1 Pro/Max notebooks
as SPI keyboard support is not in upstream Linux. This regression is in
my opinion acceptable due to the limited use of u-boot's DTBs for these
targets.
Link: https://lore.kernel.org/r/20260507-apple-dt-upstream-v2-0-35181f2b0509@jannau.net
The device tree on Apple silicon devices is passed from a previous
bootloader stage. The bootloader fills in dynamic information so
u-boot can not use its own device tree.
As documented in doc/board/apple/m1.rst it is possible to build boot
bundles (bootloader + device tree + gzipped u-boot binary). These are
useful for testing.
Instead of using u-boot's own device trees for M1 (t8103) devices use
upstream device trees from dts/upstream/src/arm64/apple. The u-boot
device trees have not seen updates since 2022. The upstream linux device
trees have feature parity for the M1 devices. In addition linux has
device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices.
Keep t8103-j274 as default device tree to avoid further updates.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
Remove outdated apple,pinctrl.yaml. The dts/upstream contains the
current version of this binding.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
These SoCs are supported since 2022/2023 but were never added to the
documentation. The devices very similar to the equivalent M1 devices.
The biggest difference is that the M2 and M2 Pro/Max based laptops no
longer use SPI for the keyboard.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
The 'part' command currently allows looking up a partition only by its
number or name.
Extend the 'number', 'start', and 'size' subcommands to support looking
up the partition via its UUID. Unlike names, UUIDs guarantee unique
partition identification, avoiding ambiguity.
The logic is updated to check if the provided string is a valid UUID
before falling back to a name-based search. The help strings for these
subcommands are updated accordingly.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the past, we only had one network stack which was called NET. The
network features were enabled for the legacy (and then only) networking
stack since commit 22353fa6b5 ("bootstd: Add some default filesystems
and commands"). Then instead on relying on NET legacy stack for enabling
networking features, the dependencies were (mostly) changed to depend on
CMD_NET in commit a0c739c184 ("boot: Create a common BOOT_DEFAULTS for
distro and bootstd"). Then a new stack (lwIP) appeared, then CMD_NET was
made available with this new stack in commit 98ad145db6 ("net: lwip:
add DHCP support and dhcp commmand") making the networking features
possible to enable and finally commit f1e978fd54 ("boot: Update tests
around network symbols in BOOT_DEFAULTS_CMDS") made it explicit that we
need *a* network stack to enable some networking features.
Align the bootstd documentation with what's actually implemented as
Kconfig dependencies. Note that BOOTSTD_DEFAULTS selects BOOT_DEFAULTS
which selects BOOT_DEFAULTS_CMDS which then selects network features.
The CMDLINE symbol needs to be enabled as well for BOOT_DEFAULTS to
select BOOT_DEFAULTS_CMDS, but I don't think we need to go that far into
explaining what's required to enable some commands.
Reported-by: Simon Glass <sjg@chromium.org>
Closes: https://lore.kernel.org/u-boot/CAFLszTgZC1FGy8965pHiG-u=FhrguftRv41ghQ_Qb_RRXx6tyg@mail.gmail.com/
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
We cannot use .clang-format without modification. For instance U-Boot
has some for each macros that Linux does not have.
Adjust the description.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add fTPM support documentation including an overview, configuration
steps for RPMB provisioning, OP-TEE TA build instructions, and
verification procedure.
Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
Add build steps for building U-Boot in secure state with
TF-A and OP-TEE. It includes the full steps for building
OP-TEE and TF-A to use with U-Boot. Also a short description
how to invoke QEMU with enabled EL3 and EL2. EL3 (machine
option secure=on) is required to run TF-A.
Signed-off-by: Johannes Krottmayer <krotti83@proton.me>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Quentin Schulz <foss+uboot@0leil.net> says:
This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.
The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?
No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.
This was tested based on 70fd0c3bb7 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.
#!/usr/bin/env bash
set -o pipefail
set -eux
ARGS="-BvelPEWM --reproducible-builds --step 0"
./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $*
./tools/buildman/buildman -o ${O} $ARGS -Ssd $*
O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt
I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.
The summary is the following:
aarch64: (for 537/537 boards) all +0.0 rodata +0.0
uniphier_v8 : all +1 rodata +1
u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
function old new delta
data_gz 10640 10641 +1
arm: (for 733/733 boards) all -0.0 rodata -0.0
uniphier_v7 : all -1 rodata -1
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
function old new delta
data_gz 11919 11918 -1
opos6uldev : all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 18778 18775 -3
uniphier_ld4_sld8: all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 11276 11273 -3
stemmy : all -20 rodata -20
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
function old new delta
data_gz 15783 15763 -20
As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.
Here is the diff for the 5 defconfigs listed above, generated with:
for f in build/*-m; do
diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done
(-m is the build directory for master, and without the suffix, it's the
top commit of this series)
"""
--- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200
+++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200
@@ -970,4 +969,0 @@
-
-#
-# Networking
-#
@@ -975,0 +972 @@
+CONFIG_NET_LEGACY=y
--- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200
+++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200
@@ -733,4 +732,0 @@
-
-#
-# Networking
-#
@@ -738,2 +733,0 @@
-# CONFIG_NET is not set
-# CONFIG_NET_LWIP is not set
--- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200
+++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200
@@ -997,4 +996,0 @@
-
-#
-# Networking
-#
@@ -1002,0 +999 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200
+++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200
@@ -1004,4 +1003,0 @@
-
-#
-# Networking
-#
@@ -1009,0 +1006 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200
+++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200
@@ -875,4 +874,0 @@
-
-#
-# Networking
-#
@@ -880,0 +877 @@
+CONFIG_NET_LEGACY=y
"""
This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
(old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
be part of .config,
GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849
It passes.
Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
TPL_NET symbol never existed in the first place, so let's remove this
misleading piece of documentation.
Fixes: 143c9a7e9d ("doc: describe TPL/VPL/SPL boot")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n,
when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so
let's simplify the various checks across the codebase.
SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so
the proper symbol is still defined in SPL whenever needed.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Highlight that NET really is the legacy networking stack by renaming the
option to NET_LEGACY.
This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise
CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL.
The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is
using the legacy networking app so this seems fine to do.
This also has the benefit of removing potential confusion on NET being a
specific networking stack instead of "any" network stack.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
This series reworks the FIT test (test_fit.py) to make it easier to
maintain and extend. It fixes the buildconfigspec so the test actually
runs on sandbox, avoids unnecessary U-Boot restarts, renames the main
test for easier selection, adds a missing-kernel check, fixes Python
warnings, converts the test to use a class, splits into separate test
functions, and adds Sphinx documentation.
Link: https://lore.kernel.org/r/20260413130007.1987326-1-sjg@chromium.org
Add a Sphinx automodule page for test_fit.py so it appears in the pytest
documentation alongside the other test modules. The index already uses a
glob pattern, so this is picked up automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
signed_hdmi_imx8m.bin is already signed and has a IVT header. It should not
be put in u-boot-spl-mkimage.signed.bin. Move it to head of flash.bin
following NXP imx-mkimage. Keeping it in u-boot-spl-mkimage.signed.bin also
consumes a lot of TCM space which is not expected.
While moving it to head of flash.bin, other changes are required,
u-boot.itb is put at sector 768 per defconfig, so u-boot.itb binman
offset should be updated and it should be moved out from binman section.
Also binman symbol address are updated, so need to subtract u-boot-spl
image_pos + CONFIG_SPL_TEXT_BASE to find the correct location of ddr phy
firmware.
Because there is 1KB padding in HDMI firmware, use 32KB when burning
flash.bin to sd card.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When the J784S4-EVM is configured for PCIe Boot, the Bootloaders are to
be written to the address specified by particular BARs. The existing
documentation hard-codes the address corresponding to the BAR under the
assumption that the Root-Complex transferring the Bootloaders is also
a J784S4-EVM. The Root-Complex assigns addresses to the BARs depending
on the currently available set of free system addresses. Since the free
system addresses vary with the Root-Complex being used, instead of
hard-coding the BARs, automate the process of identifying the appropriate
BAR in the form of a command to be run by the user on the Root-Complex.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
The title should be 'Contributing' as this is not the 'Overview' of the
U-Boot project.
The top title should be H1, the other titles H2.
Fixes: 0290cec364 ("Add an initial CONTRIBUTE.rst")
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The bootcount variable is only incremented
when the upgrade_variable is non-zero,
as implemented in drivers/bootcount/bootcount_env.c
Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
These files are now auto-generated by the binman_docs Sphinx extension
during the doc build, so the committed copies and their symlinks in
doc/develop/package/ are no longer needed.
Update binman.rst to reference the Sphinx extension instead of the
manual generation commands.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rebased to apply file deletions cleanly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently entries.rst and bintools.rst are generated manually by running
'binman entry-docs' and 'binman bintool-docs', then committed to the
repo. This means the docs can drift out of date when docstrings are
updated but the RST files are not regenerated.
Add a Sphinx extension (binman_docs) that provides two custom
directives:
.. binman-entry-docs::
.. binman-bintool-docs::
These parse the etype and btool source files using the ast module to
extract class docstrings, then insert the documentation directly into
the document tree. This avoids the need to import binman modules (which
have dependencies like libfdt that are not available in the ReadTheDocs
build environment) and avoids writing any intermediate files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a paragraph to explain how to get the address of the goldfish
tty and use it as the debug uart. I think the address is actually
fixed right now but it might change in the future.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Fix the link to the 2026.04 stats page. It was likely copied from the
2026.01 line below and not updated.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a contributors file to provide a high level overview
for people who wish to contribute to the project outlining
basic details and setting some project expectations.
This isn't intended to replace any of the existing documentation
but rather provide a succinct top level document that's easy
to find to enable users to understand the project and get
started as quickly as possible.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Correct merge window length, release day and typo in the main
index]
Signed-off-by: Tom Rini <trini@konsulko.com>
As the PHYTEC phyCORE-i.MX91 [1] is just another variant of the existing
PHYTEC phyCORE-i.MX93 SoM but with i.MX91 SoC populated instead, add it
to the existing board-code "phycore_imx93", and rename that board to
"phycore_imx91_93" to reflect the dual SoCs support. While at it, also
rename and change common files accordingly. This way i.MX91 and i.MX93
SoC variants of the phyCORE SoM share most of the code and documentation
without duplication, while maintaining own device-tree and defconfigs
for each CPU variant.
Supported features:
- 1GB LPDDR4 RAM
- Debug UART
- EEPROM
- eMMC
- Ethernet
- SD-card
- USB
Product page SoM:
[1] https://www.phytec.eu/en/produkte/system-on-modules/phycore-imx-91-93/
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
