iMX91 is reduced part from iMX93 with part number: i.MX9131/11/01
It removed A55_1, M33, MIPI DSI, LVDS, etc.
i.MX9131:
- Support 2.4GT/s DDR and HWFFC at 1.2GT/s
i.MX9121:
- A55 at 800Mhz and DDR at 1600MTS, with low drive mode.
i.MX9111:
- Support 1.6GT/s DDR and HWFFC at 800MT/s
i.MX9101:
- Support 800Mhz ARM clock
- Support 1.6GT/s DDR and HWFFC at 800MT/s
- No parallel display, eQOS, flexcan
Updated Clock/Container/CPU and etc for i.MX91
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
According to iMX93 fuse burn plan, all 9x9 parts will have USB2,
ENET1 (FEC), LVDS1, CSI1 and DSI1 disabled. The codes missed ENET1
fuse when detecting 9x9. Although it still can detect 9x9 correctly,
we add the ENET1 fuse to the check to be more accurate.
Fixes: 58da865e27f ("imx9: add i.MX93 variants support")
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Replace '#if DEBUG' with '#ifdef DEBUG', otherwise '#define DEBUG 1'
should be used and conflict with '#define DEBUG' in include/log.h
Fixes: 5fda95fb944 ("imx: imx9: Add TRDC driver for TRDC init")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Bryan Brattlof <bb@ti.com> says:
Hello Everyone!
This small series converts TI's AM65x reference board to use
CONFIG_OF_UPSTREAM and removes the unused device tree files from
arch/arm/dts.
Because it's the last board using a AM65x without enabling OF_UPSTREAM
it allows us to also remove all the SoC FDT files as well and keep a
single version of the SoC's DT files in the dts/upstream directory going
forward.
Link: https://lore.kernel.org/r/20241121-am65x-v1-0-fe87aff1b5fc@ti.com
Rather than rely on manual updates from the arch/arm/dts directory,
enable CONFIG_OF_UPSTREAM to receive automatic device tree updates for
the am65x reference board.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Updated PLL driver sequencing requires us to use udelay in the PLL
driver as there is no poll bit to get the status of operations.
tick-timer(mcu_timer0/main_timer0) setting up the clocks for itself is
something that won't work as the PLL driver will be using udelay and
PLLs are configured during clock probe which would end up in a recursive
probe.
tick-timer being used by K3 devices are configured by ROM and we really
don't need to configure any of the clocks.
Remove the clock dependency from R5 stage as we don't need to setup
clocks for it.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Aniket Limaye <a-limaye@ti.com> says:
This series adds OPP_LOW spec data in k3_avs driver and enables a config
option to select the OPP_LOW performance point.
J7200 SOC supports OPP_LOW and OPP_NOM as two Operating Performance
Points as per (7.5 Operating Performance Points) section in the
Datasheet [0].
- A72SS/MSMC at 2 GHz/1GHz operation must use OPP_NOM.
- A72SS/MSMC at 1 GHz/500 MHz operation can use OPP_NOM or OPP_LOW
voltage (though OPP_LOW voltage is recommended to reduce power
consumption).
The actual OPP voltage for the device is read from the efuse and
updated in k3_avs_probe().
The default j7200 devicetree and k3_avs driver set OPP_NOM spec
frequency and voltage.
In the board init file, if K3_OPP_LOW config is enabled, Check if
OPP_LOW AVS voltage read from efuse is valid and update frequency (A72
and MSMC) and voltage (VDD_CPU) as per the OPP_LOW spec.
[0]: https://www.ti.com/lit/gpn/dra821u (J7200 Datasheet)
Test logs:
https://gist.github.com/aniket-l/328ad93ed60c2419ed7be9f85e6b6075
- With series applied on master and CONFIG_K3_OPP_LOW enabled in
j7200_evm_r5_defconfig
- Logs shown with and without efuse register programmed for OPP_0
(Errors out if OPP_0 not found, programs OPP_LOW spec if found)
- Voltage update verified using 'i2c md 0x4c 0xe' in u-boot
- Frequency update verified using 'k3conf clock dump' in linux
Link: https://lore.kernel.org/r/20241119003617.1871183-1-a-limaye@ti.com
Define new CONFIG_K3_OPP_LOW under arm/mach-k3/r5/Kconfig and add
default value to j7200_evm_r5_defconfig
Signed-off-by: Reid Tonking <reidt@ti.com>
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
The default j7200 devicetree and k3_avs driver set 2GHz/1GHz frequency
for A72/MSMC clks and the OPP_NOM voltage.
J7200 SOCs may support OPP_LOW Operating Performance Point:
1GHz/500MHz clks for A72/MSMC and OPP_LOW AVS voltage read from efuse.
Hence, add a config check in board_init_f() to select OPP_LOW specs:
- Check if OPP_LOW AVS voltage read from efuse is valid.
- Use the device IDs and clock IDs (TISCI docs [0]) to find the A72 and
MSMC clock frequencies in the devicetree.
- Fixup the clock frequencies in devicetree as per OPP_LOW spec.
k3_avs driver programs the OPP_LOW AVS voltage for VDD_CPU through
k3_avs_notify_freq() callback from clk_k3.
[0]: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
The j7200 SOC has a single DDR controller and hence no need for
configuring the MSMC interleaver. Hence we do not have an explicit node
for MSMC in j7200 DT, unlike j721s2/j784s4.
Also, MSMC clk id is described under A72SS0_CORE0 Device in TISCI
documentation [0].
Considering the above, define the MSMC clk in the a72 node.
[0]: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html#clocks-for-a72ss0-core0-device
Signed-off-by: Reid Tonking <reidt@ti.com>
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Add the VTM node to the R5 boot stage so that AVS is correctly
configured for AM68 SK.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Add VTM node to R5 boot stage so that AVS gets correctly configured for
J784S4 EVM and AM69 SK.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Introduce CONFIG_PHYTEC_K3_DDR_PATCH to make DDR timing patch code
optional for PHYTEC K3 boards. This allows better control over which
boards receive DDR timing patches, rather than compiling the code for
all boards with K3_DDRSS enabled.
Also enable the feature by default for PHYCORE_AM62X_R5.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Given that ARCH_SUNXI already implies that USB_GADGET should be enable,
we should also imply USB being enabled.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
It is not the case that we can only pick ASPEED_AST2500 if DM_RESET
is enabled, but rather choosing ASPEED_AST2500 means we must select
DM_RESET.
Signed-off-by: Tom Rini <trini@konsulko.com>
It doesn't make sense for these files to have the x bit set. It was,
probably accidentally, added in:
Fixes: 2c494e62c31a (arm: dts: Stratix10: Add QSPI node)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Enable PCIe/NVMe support on Data Modul i.MX8M Mini eDM SBC. Except for
the configuration options which are enabled, add slight adjustment
to board u-boot.dtsi, which is necessary as there is currently no
driver for the I2C PCIe clock generator. Since the generator is
strapped to be always on, it is possible to supplant the generator
functionality by fixed-clock.
Signed-off-by: Marek Vasut <marex@denx.de>
The YModem support in SPL was never really used on this device,
the SDP support is much more convenient on i.MX8M Mini based
hardware. Replace the YModem support with SDP support.
The SDP can be utilized by forcing the board into SDP boot mode
by grounding test point right next to silkscreen label U30, and
then by using mfgtools 'uuu -brun spl flash.bin' once the device
enumerates on host system USB bus. The SDP capable USB port is
available on the USB micro-B port on the base board.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The DRAM configuration GPIO straps must be accessible in SPL and before
relocation because the GPIOs are sampled both in U-Boot SPL as well as early
on in U-Boot proper. The already present bootph-pre-ram DT property made the
GPIO controllers available in SPL, but not early on in U-Boot proper, which
made gpio_request_list_by_name_nodev() in board dmo_get_memcfg() fail. Add
missing bootph-some-ram DT property to all GPIO controllers which are
referenced in dmo,ram-coding-gpios DT property to make those GPIO
controllers available early in U-Boot proper as well.
Fixes: 8c103c33fb14 ("dm: dts: Convert driver model tags to use new schema")
Signed-off-by: Marek Vasut <marex@denx.de>
u-boot.itb has been generated via mkimage_fit_atf.sh but it is on the way
out that's why convert it's description to binman.
Compare to script binman description is not able to configure BL31 and BL32
load/entry addresses which should be done separately.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/90b613796aee38158252c8bb1dfc3da0420f089d.1730452668.git.michal.simek@amd.com
There is necessary to do some steps to compose boot images. These steps
were in scripts in layers for a while. That's why introduce description via
binman to simplify wiring and remove all scripting around.
This should make sure that everybody is up2date with the latest versions.
The first step is to create fit image with DTBs with descriptions in
configuration node which is written as regular expression to match all SOM
versions.
Description is there for k24 and k26 in spite of low level psu_init
configuration is different. The reason is that it goes to u-boot.itb image
which is the same for k24 and k26.
u-boot.itb is another image which is generated. It is normally generated
via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to
be deprecated.
FIT image by purpose is using 64bit addresses to have default option to
move images to high DDR (above 4GB). TF-A and TEE are optional components
but in the most cases TF-A is present all the time and TEE(OP-TEE) is used
by some configurations too.
3rd generated image is boot.bin with updated user field which contains
version number. This image can be used with updated Image Selector
which supports A/B update mechanisms with rollback protection.
4th image is image.bin which binary file which contains boot.bin and
u-boot.itb together and can be programmed via origin Image Selector.
This image can be also used for creating one capsule which contains both
boot images (in SPL boot flow).
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/35bc47a4a4799c5f5dbea56a45340a2810538330.1730452668.git.michal.simek@amd.com
Make use of OF_UPSTREAM which uses Linux dts.
Signed-off-by: david regan <dregan@broadcom.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Anand Gore <anand.gore@broadcom.com>
The x250 and SE250 are series of 10G L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Use standard boot instead of the distro boot scripts. Regenerate the
board defconfig now that some options are selected automatically.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
The phyCORE-i.MX 93 is available in various variants (e.g. different ram
sizes, eMMC HS400 yes/no). Enable hardware introspection for the
imx93-phyboard-segin_defconfig, so that during startup the SOM module
variant can be detected, and the hardware can be configured accordingly.
The resulting SPL and u-boot binary shall able to boot each
phyCORE-i.MX 93 module variant on each carrier board. Finally rename
imx93-phyboard-segin_defconfig to imx93-phycore_defconfig, to highlight
its SOM scope.
Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
The phyCORE-i.MX 93 is available in various variants. Relevant variant
options for the spl/u-boot are:
- with or without HS400 support for the eMMC
- with 1GB ram chip, or 2GB ram chip
The phyCORE's eeprom contains all information about the existing variant
options. Add evaluation of the eeprom data to the spl/u-boot to
enable/disable HS400 and to select the appropriate ram configuration at
startup.
Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Primoz Fiser <primoz.fiser@norik.com>
current generated flash.bin image does not longer
boot on cxg3 board.
Rename bootph-pre-ram to bootph-all so flash.bin
boots again!
Add u-boot specific change (add bootph-all property)
in A35_0 node to imx8qxp-capricorn-u-boot.dtsi
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
We have many HW with capricorn i.MX8X boards. The difference in u-boot is
at all by the display of the LEDs.
* put upstream a reference project & board for DT and defconfig
* use the capricorn prefix outside the board/siemens/capricorn folder
Signed-off-by: Enrico Leto <enrico.leto@siemens.com>
Signed-off-by: Heiko Schocher <hs@denx.de>
imx8qxp based boards which use SPL drop error when
calling make all:
"""
Writing image to './flash.bin'
Node '/binman/imx-boot/spl': GetData: size 0x0
Node '/binman/imx-boot': GetPaddedDataForEntry: size 0x0
Node '/binman/imx-boot': GetData: 1 entries, total size 0x0
Node '/binman/imx-boot': GetPaddedDataForEntry: size 0x0
Wrote 0x0 bytes
Image 'imx-boot' is missing external blobs and is non-functional: spl
/binman/imx-boot/spl (spl.bin):
Missing blob
Some images are invalid
"""
Guard creation of flash.bin with CONFIG_XPL_BUILD option.
Signed-off-by: Heiko Schocher <hs@denx.de>
Fixes: c9713c155127 ("imx8-u-boot: Fix SPL guard option")
u-boot was crashing in qemu as the modeled hardware enforced overly
strict memory reads.
While this code will work on existing hardware, fix to avoid future issues.
Fixes: 12770d0df0e8 ("ast2600: spl: Add boot mode detection")
Link: https://gitlab.com/qemu-project/qemu/-/issues/2636
Signed-off-by: Joel Stanley <joel@jms.id.au>
Janne Grunau <j@jannau.net> says:
Starting with v2024.10 dev_iommu_dma_unmap calls during device removal
trigger a NULL pointer dereference in the Apple dart iommu driver. The
iommu device is removed before its user. The sparsely used DM_FLAG_VITAL
flag is intended to describe this dependency. Add it to the driver.
Adding this flag is unfortunately not enough since the boot routines
except the arm one simply remove all drivers. Add and use a new function
which calls
dm_remove_devioce_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL);
dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
to ensure this order dependency is head consistently.
Link: https://lore.kernel.org/r/20241123-iommu_apple_dart_ordering-v2-0-cc2ade6dde97@jannau.net
This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.
Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.
Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.
dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.
Signed-off-by: Janne Grunau <j@jannau.net>
Since 50cdd3f74af3 ("clk: imx: clk-imx8mn Fix nand and spi clock parent"),
drivers/clk/imx/clk-imx8mn.c clk_get_by_name(dev, "osc_24m", &osc_24m_clk)
fails with error -22 EINVAL in SPL. This is because clk_get_by_name() in the
end calls fdtdec_parse_phandle_with_args(), which iterates over all phandles
in clock-controller@30380000 { clocks = <&osc_32k>, <&osc_24m>, ... } node
'clocks' property in an attempt to find the "osc_24m" clock, but fails to
resolve the &osc_32k phandle and returns with -EINVAL.
Include the osc_32k clock in SPL DTs as a low risk fix for v2025.01 release.
This way, fdtdec_parse_phandle_with_args() can resolve both the osc_32k and
following osc_24m phandle and successfully look up the osc_24m clock.
Fixes: 50cdd3f74af3 ("clk: imx: clk-imx8mn Fix nand and spi clock parent")
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Adam Ford <aford173@gmail.com> #imx8mn-beacon
