Currently in j721e_init.c we check which firewalls to remove using
the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this
as J721e and J7200 have different IP and firewalls but use the same
SoC definition (SOC_K3_J721E) even though they are different SoCs.
The idea was they would be similar enough that they both could use
the same SoC config to help with common code sharing. Board checks
would then be used differentiate.
This has grown far too messy to maintain any more, especially now
that there is more than one board using J721e (EVM, SK, Beagle AI64).
As differentiation is done based on board, every one of these boards
would have to have checks added for them. Instead let's split J7200
support out from J721e like how normal new SoC support is done.
This patch touches several subsystems and could not be split much better
as when we add SOC_K3_J7200 we want to make use of it in all spots that
once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when
building for J7200 boards.
Signed-off-by: Andrew Davis <afd@ti.com>
Harsha Vardhan V M <h-vm@ti.com> says:
This patch series introduces the fuse writebuff sub-system command and
makes improvements to the existing fuse implementation by removing the
custom string functions. The patches are required to be applied in
sequence.
The series consists of the following changes:
Patch 1 removes custom string functions and replaces them with standard
string functions.
Patch 2 introduces fuse.rst documentation for fuse commands.
Patch 3 introduces the fuse writebuff sub-system command, allowing to
write a structured buffer in memory to fuses, and implementing the
necessary function calls.
Patch 4 enables the fuse sub-system in the K3 platform.
Patch 5 updates the fuse.rst documentation to include details about the
new fuse writebuff command.
These changes aim to improve the fuse sub-system by the removal of
custom string functions and the addition of the fuse writebuff
command improves fuse programming workflows by allowing to write a
structured buffer in memory to efuses.
Link: https://lore.kernel.org/r/20250319084714.335777-1-h-vm@ti.com
Add K3_FUSE config option to add and enable fuse sub-system
implementation function calls.
Signed-off-by: Harsha Vardhan V M <h-vm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
The membuff implementation curently has no tests. It also assumes that
head and tail can never correspond unless the buffer is empty.
This series provides a compile-time flag to support a 'full' flag. It
also adds some tests of the main routines.
The data structure is also renamed to membuf which fits better with
U-Boot.
There may be some cases in the code which could be optimised a little,
but the implementation is functional.
Link: https://lore.kernel.org/r/20250318152059.1464369-1-sjg@chromium.org
The double 'f' is not necessary and is a bit annoying as elsewhere in
U-Boot we use 'buf'. Rename all the functions before it is used more
widely.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
is not perfect.
With both builds, executing the VESA ROM causes an intermittent hang, at
least on some AMD CPUs.
With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
is done in a way that works on real hardware but not with QEMU. This
means that performance is 4-5x slower than it could be, at least on my
CPU.
We can work around the first problem by using Bochs, which is anyway a
better choice than VESA for QEMU. The second can be addressed by using
the same descriptor across the jump to long mode.
With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
In v3 some e820 patches are included to make booting reliable and avoid
ACPI tables being dropped. Also, several MTTR problems are addressed, to
support memory sizes above 4GB reliably.
Link: https://lore.kernel.org/all/20250315142643.2600605-1-sjg@chromium.org/
The existing QEMU implementation mostly ignored BLOBLIST_TABLES and
allocates the bulk of the tables with malloc(). Update it to place all
tables in the bloblist. Since QEMU declares a size of 128KB regardless
of the size of its tables, this requires a larger bloblist.
Fix up the e820 table to handle this, keeping the old code as an option
for now, to assist with any future bug-fixing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Manorit Chawdhry <m-chawdhry@ti.com> says:
The series adds support for J742S2 family of SoCs. Also adds J742S2 EVM
Support and re-uses most of the stuff from the superset device J784s4.
This device is a subset of J784S4 and shares the same memory map and
thus the code is being reused from J784S4 to avoid duplication.
It initially cleans up the J784s4 and AM69 files so that they can be
re-usable for j742s2 and then it introduces J742S2.
The DT for the following SoC will be coming to U-boot during 6.13 Sync
so the series is kept as RFC till then.
Here are some of the salient features of the J742S2 automotive grade
application processor:
The J742S2 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration in automotive, ADAS and industrial
applications requiring AI at the network edge. This SoC extends the K3
Jacinto 7 family of SoCs with focus on raising performance and
integration while providing interfaces, memory architecture and compute
performance for multi-sensor, high concurrency applications.
Some changes that this devices has from J784S4 are:
* 4x Cortex-A72 vs 8x Cortex-A72
* 3x C7x DSP vs 4x C7x DSP
* 4 port ethernet switch vs 8 port ethernet switch
* 2 DDR controller vs 4 DDR controller
Test logs:
https://gist.github.com/manorit2001/f7df0e8cca1e9973b4361f0559c6f53d
Link: https://lore.kernel.org/r/20250317-b4-upstream-j742s2-v4-0-4ba88bfd357a@ti.com
Re-use j784s4 clocks and power domains for j742s2 family of device.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
J742S2 has the same part number as J784S4 but JTAG_DEVICE_ID has a
PKG bit that tells about J742S2.
Add support for reading JTAG_DEVICE_ID and set family as J742S2 based
on that.
Link: https://www.ti.com/lit/pdf/spruje3 (TRM)
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The end of the ACPI table is set to 'addr' instead of 'end'. The ACPI
code for QEMU relies on those values to mark memory as 'ACPI Reclaim'
and as a result the ACPI RSDP ends up in Boot services Data.
Reported-by: Björn Töpel <bjorn@kernel.org>
Fixes: commit 638cc363484b ("acpi: enable writing ACPI tables on QEMU")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We have three warnings about needing to use quotes around some strings
in Kconfig files today. In two of these cases we can just add the
missing strings. In the case of INTEL_PINCTRL_PADCFG_PADTOL the symbol
is never referenced and should be dropped.
Signed-off-by: Tom Rini <trini@konsulko.com>
Christian Marangi <ansuelsmth@gmail.com> says:
This little series adds initial support for Airoha AN7581 SoC.
With the help of some backport patch, this use OF_UPSTREAM
directly.
Posting this to have the targer and the very basic driver.
Ethernet, SNAND and eMMC support is already ready downstream
and will be posted shortly after this gets approved.
Having the first driver ready permits to separately push
dedicate series for SNAND, eMMC and Ethrnet as they all depends
on basic support of clock and reset and nothing else.
Link: https://lore.kernel.org/r/20250314185941.27834-1-ansuelsmth@gmail.com
Add driver for controlling the reset lines of AN7581. This is a detached
version of the clock controller driver present in Linux only used to
control reset lines. Driver gets loaded with the bind of the clock
driver and doesn't require a compatible. This is needed as they share
the same registers.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add support for Airoha AN7581 SoC clock driver. This mainly needed for
eMMC support to correctly get the current clock applied.
Based on the Linux clk-en7523.c but majorly reworked for U-Boot that
doesn't require CCF subsystem.
Major modification, support for set_rate, realtime get_rate and split
for reset part to a different driver.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The commit 211b3d726378 ("arm: dts: am3x: Non-functional changes sync
with v6.3-rc6") changed the tilcdc clock names.
Fix the tilcdc driver to use the new clock names.
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>
This patch adds pwm support for MediaTek MT7987 SoC.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Some drivers set DM_FLAG_PROBE_AFTER_BIND, this does nothing since it's
only every applied on a per-device basis.
Remove the flags.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Michal Simek <michal.simek@amd.com>
Pass DBSC5 udevice and MODEMR0 register values to board specific
function dbsc5_get_board_data(). The board specific implementation
of dbsc5_get_board_data() can return struct renesas_dbsc5_board_config
which matches the board based on the content of MODEMR0 or content
of DT accessible via the udevice.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Extract wait for completion code from dbsc5_send_dbcmd2() into
new separate function dbsc5_wait_dbwait(). This extracted code
can be used to implement MR register read in the future.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Update dbsc5_send_dbcmd2() such that it takes multiple parameters
instead of one magic register content value. These parameters are
used to form the same resulting register value internally in the
dbsc5_send_dbcmd2() function, but from well defined input constants.
The new input constants are the operation code, channel, rank, and
operation argument. The argument is operation code specific, therefore
it is still a 16-bit magic number, but the rest of the arguments are
now split up. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename dbsc5_ddr_register_read() to dbsc5_ddr_register_mr27_mr57_read()
and dbsc5_ddr_register_set() to dbsc5_ddr_register_mr28_set() to make
it clear what those functions really do. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Assorted fixes, refactorings and additions that are ready, and shave
off some load from upcoming series'.
Improves MMC performance on D1/T113 (missed clock divider), enables
eMMC access on the H616 family (never worked, many thanks to Jernej for
the fix!), DRAM detection fixes for the H616 (now reportedly stable).
Some patches for the upcoming Allwinner A133 SoC support: a few
refactorings, plus the DM clock and pinctrl driver. The DRAM init
routines work, but need some more polishing, that also holds back the
actual enablement patch, which will hopefully follow for v2025.07 still.
Also some preparatory patches for the Allwinner A523 SoC support, for
now just to improve the FEL save/restore code. There will be more patches
coming up for this, ideally also in the coming cycle still.
Gitlab CI passed, and I booted that briefly on some boards.
Cards should always be reset and threshold set. This fixes eMMC on H616.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[Andre: use macro-defined offsets to fix build on older SoCs]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The Allwinner A100 SoC has been around for a while, and has now seemingly
been replaced with its close sibling A133.
Add the required mapping between the pinmux group strings and their
respective mux value, as far as used by U-Boot proper. Linux has some
basic (clock and pinctrl) support for a while, so we can build on the
names already used there.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The Allwinner A100 SoC has been around for a while, and has now seemingly
been replaced with its close sibling A133.
Add support for the CCU, as far as used by U-Boot proper. Linux has some
basic (clock and pinctrl) support for a while, so we can already use the
existing binding headers.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Some of the X-Power AXP PMICs can be ordered with an alternative I2C
address, for instance an AXP717 could be shipped with address 0x34 or
with address 0x35. Similarly the AXP803 lists two possible addresses.
For DM (DT) based drivers this is no problem, but the Allwinner SPL
code relies on exactly one hardcoded address per PMIC so far.
Add a Kconfig variable that holds the I2C address used by the PMIC
accessed in the SPL, and provide the (mostly only one) supported address
as its default, for the PMICs we use. Boards using the other address
can easily set this in their defconfig.
This effectively moves the hardcoding from C code to Kconfig.
That enables to use the AXP717 on some boards with the new Allwinner
A523 chip, which use the other I2C address there.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
The AXP803 has been around for about a decade now, but so far we didn't
need SPL support, since the DRAM rail was wired up correctly at reset.
Now some boards using the A133 SoC use the (compatible) AXP707 with DDR4
memory, which requires the SPL to set the required 1.1V voltage manually.
Add the descriptions for the DC/DC regulators of the AXP803, and enable
that when CONFIG_AXP803_POWER is enabled.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
On the Allwinner D1/R528/T113-s3 SoCs the MMC clock source selected by
mux value 1 is PLL_PERIPH0(1x), not (2x), as in the other SoCs.
But we have still the hidden divisor of 2 in the MMC mod clock, so
need to explicitly compensate for that on those SoCs.
This leads to the actually programmed clock rate to be double compared
to before, which increases the MMC performance on those SoCs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Kuba Szczodrzyński <kuba@szczodrzynski.pl>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The EFI HTTP boot puts the ISO installer image at some location in
memory. Information about this image has to be passed on to the OS
kernel, which is done by adding a persistent memory(pmem) node to the
devicetree(DT) that is passed to the OS. The OS kernel then gets
information about the presence of this ISO image and proceeds with the
installation.
In U-Boot, this ISO image gets mounted as a memory mapped blkmap
device slice, with the 'preserve' attribute. Add a helper function
which iterates through all such slices, and invokes a callback. The
callback adds the pmem node to the DT and removes the corresponding
memory region from the EFI memory map. Invoke this helper function as
part of the DT fixup which happens before booting the OS.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Some blkmap memory mapped devices might have to be relevant even
after U-Boot passes control to the next image as part of the platform
boot. An example of such a mapping would be an OS installer ISO image,
information for which has to be provided to the OS kernel. Use the
'preserve' attribute for such mappings. The code for adding a pmem
node to the device-tree then checks if this attribute is set, and adds
a node only for mappings which have this attribute.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add information about the type of blkmap slices as an attribute in the
corresponding slice structure. Put information in the blkmap slice
structure to identify if it is associated with a memory or linear
mapped device. Which can then be used to take specific action based on
the type of the blkmap slice.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Much of the data that is display by imx8_cpu.c is also displayed from
arch/arm/mach-imx/cpu.c, except the temperature grade and active
temperature are only displayed when SoC is an i.MX9. Since IMX9 now
implies IMX_TMU, change this to check for IMX_TMU in the same way
it's done in mach-imx/cpu.c to enable displaying this information
for any SoC with either of this config enabled.
Since additional text may appear due to this commit, remove
the extra space in the message displaying the temperature
grade.
Before:
CPU: NXP i.MX8MP Rev1.1 A53 at 1200 MHz
Model: Beacon EmbeddedWorks i.MX8MPlus Development kit
After:
CPU: NXP i.MX8MP Rev1.1 A53 at 1200 MHz
CPU: Industrial temperature grade (-40C to 105C) at 28C
Model: Beacon EmbeddedWorks i.MX8MPlus Development kit
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The imx8_cpu is capable of running on IMX8, IMX8M, and IMX9
families, but the CPU list is limited on the 8M variants. Expand
this list to show more variants and their respective names.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
These helpers wrongly return the updated register value. As a non-zero
value indicates failure, this causes various clock operations are
considered failed.
Correct the return value to constant zero, since these simple MMIO
operations won't fail. This fixes clock enabling failures during booting
process,
In: serial@4140000
Out: serial@4140000
Err: serial@4140000
Net: Enable clock-controller@3002000 failed
failed to enable clock 0
No ethernet found.
which leads to misoperation of various peripherals.
Fixes: 5f364e072e7 ("clk: sophgo: cv1800b: Add clock controller driver for cv1800b SoC")
Tested-by: Yuguo Pei <purofle@gmail.com>
Signed-off-by: Yao Zi <ziyao@disroot.org>
take 2
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtlGhRjxqvtBpDFXNBYMxKxlfZLYFAmfhkqIACgkQBYMxKxlf
ZLY5Ig/+J9R0ZC9qJxQXZHANfWRUsCwn9UDnc/cYgo6eD/E87Tgdr85vlH44JOh9
wka2ysn6H4IaN7Ca4435GUjntvuhJ85HLXhbBuQXOT27fHSIV0MJq94jvGwDzSps
IOy9JSYHhbs5tP33ekXfLYlL60BFqcTm22VXUfAXD9mMkDonbh4vq1LPxskVj8iq
85k5F2GyFm5cU4H5nQpgI+6+LQSJ/FlraOGNOYQj7MiQzTxPkWL6hC+p+9RuJAbt
NLJiDd3oQUgpo9/jQseteNXrUfQYsUmuzjrz71V2Z9saIHKw+AuVcnr/EanynjiJ
JjKdQ3Xmu3zwdTGP3/c/ZIxy1vKq4qoVnjzHo8x/am7euPNnj9lS7liq618/qhtv
AuCf6SSpXqKFMejXn/mF28sO0merI5oM3OB7AEL+BOH5HIaNr39PyAQ+8HKh5tmb
7lB1z/LjSPvpapQOZqj2XTBcNuxFT6rD4Nl5CFlJLjcGdMd6BRpCulE8z/53VSwH
FDEi0pqsN4No1anA8XMial7BEtCrM1e9NO3X+RRXCbxGZHa37fwlFmzTbpqUZcRA
iv0YmXvv2PT3+W/tuwS8d2ZgTSctFSAoKd5B9iuDiuNko/teUbKFREY7E/rB7Oky
AcNUT6ILmsqNg+BnkXu3Z+NP+Ms30FOxK/pEptek0vfLwJuAhg8=
=2n9a
-----END PGP SIGNATURE-----
Merge tag 'qcom-next-20250324' of https://gitlab.denx.de/u-boot/custodians/u-boot-snapdragon into next
qcom-next-20230324:
* msm8916 gets proper sysreset and spin-table support
* The first new IPQ platform is added - the IPQ9574. The IPQ series are
used in routers. The flashing process is also documented
* mach-snapdragon gains the ability to boot with an internal FDT and
still parse memory from an externally provided one
* SC7280 gets a pinctrl driver and various clock driver improvements.
* Qualcom clock drivers will now actually return an error when
attempting
to enable a clock which isn't described.
* Qualcomm pinctrl drivers will now return an error when attempting to
configure an invalid function mux
Pass struct udevice * into imx_clk_fixed_factor*() functions, so the
clock core would have access to parent struct udevice *.
Signed-off-by: Marek Vasut <marex@denx.de>
Use clock-names property which is accessible via parent clock OF node
to look up the parent clock by name instead of depending on unreliable
global clock name to perform look up.
Signed-off-by: Marek Vasut <marex@denx.de>
Use U-Boot specific struct udevice instead of Linux compatibility
struct device in clk-fixed-factor registration.
Signed-off-by: Marek Vasut <marex@denx.de>
