To be used for special-case oslog support in rtkit-helper.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
This driver handles the MTP ASC coprocessor, which does not need any
special handling on the RTKit side and communicates out-of-band.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
With the SPL clock code and the DRAM init routine we converted all users
of the H6 class "struct sunxi_prcm_reg" over to use #define'd register
offsets now.
Drop the whole definition of this struct now, since it's not needed
anymore, for all H6 and H616 boards.
This removes the entire fragile and questionable definition, and allows
new SoCs to share the code more easily.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The Allwinner H6 and H616 DRAM initialisation code uses a complex C
struct, modelling the PRCM clock register frame. For those SoCs, this
struct contains 20 registers, but the DRAM code only uses two of them.
Since we want to get rid of this struct, drop the usage of the struct in
the H6 and H616 DRAM code, by using #define'd register names and their
offset, and then adding those names to the base pointer.
This removes one more user of the PRCM clock register struct.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
U-Boot drivers often revert to using C structures for modelling hardware
register frames. This creates some problems:
- A "struct" is a C language construct to group several variables
together. The details of the layout of this struct are partly subject
to the compiler's discretion (padding and alignment).
- The "packed" attribute would force a certain layout, but we are not
using it.
- The actual source of information from the data sheet is the register
offset. Here we create an artificial struct, carefully tuning the
layout (with a lot of reserved members) to match that offset. To help
with correctness, we put the desired information as a *comment*,
though this is purely for the human reader, and has no effect on the
generated layout. This sounds all very backwards.
- Using a struct suggests we can assign a pointer and then access the
register content via the members. But this is not the case, instead
every MMIO register access must go through specific accessor functions,
to meet the ordering and access size guarantees the hardware requires.
- We share those structs in code shared across multiple SoC families,
though most SoCs define their own version of the struct. Members must
match in their name, across every SoC, otherwise compilation will fail.
We work around this with even more #ifdefs in the shared code.
- Some SoCs have an *almost* identical layout, but differ in a few
registers. This requires hard to maintain #ifdef's in the struct
definition.
- Some of the register frames are huge: the H6 CCU device defines 127
registers. We use 15 of them. Still the whole frame would need to be
described, which is very tedious, but for no reason.
- Adding a new SoC often forces people to decide whether to share an
existing struct, or to create a new copy. For some cases (say like 80%
similarity) this works out badly either way.
The Linux kernel heavily frowns upon those register structs, and instead
uses a much simpler solution: #define REG_NAME <offset>
This easily maps to the actual information from the data sheet, and can
much simpler be shared across multiple SoCs, as it allows to have all
SoC versions visible, so we can use C "if" statements instead of #ifdef's.
Also it requires to just define the registers we need, and we can use
alternative locations for some registers much more easily.
Drop the usage of "struct sunxi_prcm_reg" in the H6 SPL clock code, by
defining the respective register names and their offsets, then adding
them to the base pointer.
We cannot drop the struct definition quite yet, as it's also used in
other drivers, still.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
With the SPL clock code, the MMC driver, and the DRAM init routine we
converted all users of the H6 class "struct sunxi_ccm_reg" over to use
#define'd register offsets now.
Drop the whole definition of this struct now, since it's not needed
anymore, for all H6 and H616 boards.
This removes the entire fragile and questionable definition, and allows
new SoCs to share the code more easily.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The Allwinner H616 DRAM initialisation code uses a complex C struct,
modelling the clock device's register frame. For this SoC, the struct
contains 127 registers, but the DRAM code only uses four of them.
Since we want to get rid of this struct, drop the usage of the struct in
the H616 DRAM code, by using #define'd register names and their offset,
and then adding those names to the base pointer.
This removes one more user of the clock register struct.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The Allwinner MMC code uses a complex C struct, modelling the clock
device's register frame. We rely on sharing the member names across all
Allwinner SoCs, which is fragile.
Drop the usage of the struct in the MMC code, by using #define'd
register names and their offset, and then adding those names to the base
pointer. This requires to define those offsets for all SoCs, but since we
only use between four and six clock registers in the MMC code, this is
easily done.
This removes one common user of the clock register struct.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
U-Boot drivers often revert to using C structures for modelling hardware
register frames. This creates some problems:
- A "struct" is a C language construct to group several variables
together. The details of the layout of this struct are partly subject
to the compiler's discretion (padding and alignment).
- The "packed" attribute would force a certain layout, but we are not
using it.
- The actual source of information from the data sheet is the register
offset. Here we create an artificial struct, carefully tuning the
layout (with a lot of reserved members) to match that offset. To help
with correctness, we put the desired information as a *comment*,
though this is purely for the human reader, and has no effect on the
generated layout. This sounds all very backwards.
- Using a struct suggests we can assign a pointer and then access the
register content via the members. But this is not the case, instead
every MMIO register access must go through specific accessor functions,
to meet the ordering and access size guarantees the hardware requires.
- We share those structs in code shared across multiple SoC families,
though most SoCs define their own version of the struct. Members must
match in their name, across every SoC, otherwise compilation will fail.
We work around this with even more #ifdefs in the shared code.
- Some SoCs have an *almost* identical layout, but differ in a few
registers. This requires hard to maintain #ifdef's in the struct
definition.
- Some of the register frames are huge: the H6 CCU device defines 127
registers. We use 15 of them. Still the whole frame would need to be
described, which is very tedious, but for no reason.
- Adding a new SoC often forces people to decide whether to share an
existing struct, or to create a new copy. For some cases (say like 80%
similarity) this works out badly either way.
The Linux kernel heavily frowns upon those register structs, and instead
uses a much simpler solution: #define REG_NAME <offset>
This easily maps to the actual information from the data sheet, and can
much simpler be shared across multiple SoCs, as it allows to have all
SoC versions visible, so we can use C "if" statements instead of #ifdef's.
Also it requires to just define the registers we need, and we can use
alternative locations for some registers much more easily.
Drop the usage of "struct sunxi_ccm_reg" in the H6 SPL clock code, by
defining the respective register names and their offsets, then adding
them to the base pointer.
We cannot drop the struct definition quite yet, as it's also used in
other drivers, still.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Thanks for Jernej's JTAG debugging effort, it turns out that the BROM
expects SP_IRQ to be saved and restored, when we want to enter back into
FEL after the SPL's AArch64 stint.
Save and restore SP_IRQ as part of the FEL state handling. The banked
MRS/MSR access to SP_IRQ, without actually being in IRQ mode, was
introduced with the ARMv7 virtualisation extensions. The Arm Cortex-A8
cores used in the A10/A13s or older F1C100s SoCs would not support that,
but this code here is purely in the ARMv8/AArch64 code path, so it's
safe to use unconditionally.
Reported-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
To be able to return to the BootROM FEL USB debug code, we must restore
the core's state as accurately as possible after the SPL has been run.
Since the BootROM runs in AArch32, but the SPL uses AArch64, this requires
a core reset, which clears the core's state.
So far we were saving and restoring the required registers like SCTLR
and VBAR, but could ignore the interrupt controller's state (GICC), since
that lives in MMIO registers, unaffected by a core reset.
Newer Allwinner SoCs now feature a GICv3 interrupt controller, which keeps
some GIC state in architected system registers, and those are cleared
when we switch back to AArch32.
To enable FEL operation on the Allwinner A523 SoC,
Add AArch32 assembly code to save and restore the ICC_PMR and ICC_IGRPEN1
system registers. The other GICv3 sysregs are either not relevant for the
BROM operation, or haven't been changed from their reset defaults by the
BROM anyway.
This enables FEL operation on the Allwinner A523 family of SoCs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
H616 rank and size detection code is superior to the H6. Nevertheless,
they are structurally the same. Split functions from H616 into new file
and reuse them in H6 DRAM driver too. This should also fix some bugs for
H6 too, like incorrect DRAM size detection.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[Andre: back out panic if test fails to allow 2^11 columns]
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This change is same as in commit 78aa00c38e ("sunxi: H616: dram: split
struct dram_para"), but for H6. This is needed in order to extract
common code between H6 and H616 later.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
This is just cosmetic fix for later easier rework.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
The current DT bindings for the rk3576 clock use a different ID than the
one that is supposed to be written to the hardware registers.
Thus, we cannot use directly the id provided in the phandle, but rather
use a lookup table to correctly setup the hardware.
This follows the implementation done in the Linux-Kernel and also
how the rk3588 does this both in the Linux-Kernel as well as U-Boot.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
[adapted from mainline Linux code for u-boot]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Rockchip RK3576 is a ARM-based SoC with quad-core Cortex-A72
and quad-core Cortex-A53 including 6TOPS NPU, Mali-G52 MC3, HDMI Out,
DP, eDP, MIPI DSI, MIPI CSI2, LPDDR4/4X/5, eMMC5.1, SD3.0/MMC4.5, UFS,
USB OTG 3.0, Type-C, USB 2.0, PCIe 2.1, SATA 3, Ethernet, SDIO3.0, I2C,
UART, SPI, GPIO and PWM.
Add arch core support for it.
Signed-off-by: Xuhui Lin <xuhui.lin@rock-chips.com>
[adapted for mainline u-boot]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Rockchip RK3528 is a ARM-based SoC with quad-core Cortex-A53.
Add initial arch support for the RK3528 SoC.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add clock driver for RK3528.
Imported from vendor U-Boot linux-6.1-stan-rkr5 tag with minor
adjustments and fixes for mainline.
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jerome Forissier <jerome.forissier@linaro.org> says:
This series replaces the dynamic initcalls (with function pointers) with
static calls, and gets rid of initcall_run_list(), init_sequence_f,
init_sequence_f_r and init_sequence_r. This makes the code simpler and the
binary slighlty smaller: -2281 bytes/-0.21 % with LTO enabled and -510
bytes/-0.05 % with LTO disabled (xilinx_zynqmp_kria_defconfig).
Execution time doesn't seem to change noticeably. There is no impact on
the SPL.
The inline assembly fixes, although they look unrelated, are triggered
on some platforms with LTO enabled. For example: kirkwood_defconfig.
CI: https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25514
Link: https://lore.kernel.org/r/20250404135038.2134570-1-jerome.forissier@linaro.org
The mcr and msr instructions are available in Thumb mode only if
Thumb2 is supported. Therefore, if __thumb2__ is not set, make
sure we switch to ARM mode by inserting a .arm directive in the
inline assembly.
Fixes LTO link errors with kirkwood platforms, triggered by a later
commit:
tools/buildman/buildman -o /tmp/build -eP sheevaplug
[...]
{standard input}:24085: Error: selected processor does not support `mrc p15,0,r3,c1,c0,0' in Thumb mode
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
UART-A can be exposed through uSD, this was tested on Transformer T20
but should work on all Ventana-based boards.
TX is exported on SDD pingroup corresponding to uSD CLK pin
RX is exported on SDB which is CMD pin in uSD slot
Signed-off-by: Artur Kowalski <arturkow2000@gmail.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Add MIDR entries for Cortex-A55, Cortex-A73 and
Cortex-A75 cores and update the is_coretex_a entries.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
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.
To be able to return to the BootROM when booting via the FEL USB
protocol, we need to save the CPU state very early, which we need to do
in the embedded AArch32 code. At the moment the pointer to the buffer for
that state is located *after* the code, which makes the PC relative
code fragile: adding or removing instructions will change the distance
to that pointer variable.
The "new" Allwinner A523 SoC requires more state to be saved (GICv3
system registers), but we must do that *only* on that SoC. Conditional
compilation sounds like the easiest solution, but would mean that the
distance to that pointer would change.
Solve this rather easily by moving the pointer to the *front* of the
code: we load that pointer in the first instructions, so the distance
would always stay the same. Later in the code we won't need PC relative
addressing anymore, so this code can grow or shrink easily, for instance
due to conditional compilation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The names used for displaya, displayb and i2c1 do not align with their
corresponding Linux counterparts. This inconsistency can cause pins to be
configured incorrectly, potentially breaking existing functionality.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Modify the pin state lists for lock, io-reset, rcv-sel, and e-io-hv
properties by repositioning the default value to the end. This change
addresses conflicts with device tree representations of TEGRA_PIN_DISABLE
and TEGRA_PIN_ENABLE.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Patch introduces:
* chip_id API - useful for various things, but used now for
device_id (did) generation as mentioned in [1] on our private board
code. Our device_id is calculated by means of permutations of
chip_id value.
* new SoCs (a1, s4, etc) are usually coming with the support of chip_id
v2 right away, whereas secure monitors on old SoCs (like axg, g12b,
g12a, etc) may support only chip_id v1. Chip_id API handles both
cases
* meson_sm_get_serial() is described via chip_id API.
Links:
[1] https://lore.kernel.org/linux-arm-kernel/202311242104.RjBPI3uI-lkp@intel.com/T/#m630fbeea6a6e7d531290b5c0af205af4fb979757
Signed-off-by: Viacheslav Bocharov <adeep@lexina.in>
Co-developed-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>
Link: https://lore.kernel.org/r/20250210-meson_chip_id_all_vers-v1-3-b98f8b6880b8@salutedevices.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
The ARM ARM (Rev L.a) on section 8.17.1 describes the cases where
break-before-make is required when changing live page tables.
Since we can use a function to tweak block and page permissions,
where BBM is not required split the existing mmu_change_region_attr()
into two functions and create one that doesn't require BBM. Subsequent
patches will use the new function to map the U-Boot binary with proper
page permissions.
While at it add function descriptions in their header files.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tegra platforms feature native HDMI support. Implement a driver to enable
functionality. This driver will initially support Tegra 2 and 3, with
future extensibility.
Co-developed-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Separate setjmp.h into an architecture independent part and an architecture
specific part. This simplifies moving from using struct jmp_buf_data
directly to using type jmp_buf in our code which is the C compliant way.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Don't assume that u32 and u64 are already defined.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tegra 124 is fully compatible with existing Tegra pincontrol
driver, but it needs a specific MIPI PAD control pinconfig.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Since pinmux driver now is available for Tegra 2, these parts may
be removed from here and defined either in device tree or in
the device board files.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
In the GRF header file, some instances of UART2 pinmux are prefixed with
"GRF_UART2DBG" while others have "GRF_UART2DGB".
Since UART2 is the default console UART and used for debugging, it is
more likely the name should be UART2DBG.
Fix the ones that are wrong.
Fixes: a2c08df381 ("pinctrl: add driver for rk3399")
Fixes: fa72de1045 ("rockchip: arm64: rk3399: move grf register definitions to grf_rk3399.h")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The PCS exists only in GMAC1 and relates to SGMII interface and
is used to control the SGMII PHY.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
[trini: Adjust slightly for white space and to move 'start' to within if
block]
Add empty weak assembler function armv8_switch_to_el2_prep() which is
jumped to just before U-Boot determines which EL it is running in and
decides which path to take to boot the Linux kernel.
This weak function is meant to be used by architecture specific code
to implement jump to a firmware blob, which then returns right past
this weak function and continues execution of U-Boot code which then
boots the Linux kernel. One example of such use case is when U-Boot
jump tp TFA BL31, which switches from EL3 to EL2 and then returns to
U-Boot code newly running in EL2 and starts the Linux kernel.
The weak function is called with caches already disabled and DM shut
down. Any preparatory work or even loading of more data must be done
in board_prep_linux(), this hook is meant only for the final jump to
the firmware and return to U-Boot before booting Linux.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
PLLD2 is a simple clock (controlled by 2 registers) and appears starting
from T30. Primary use of PLLD2 is as main HDMI clock parent.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
PLLD2 is a simple clock (controlled by 2 registers) and appears starting
from T30. Primary use of PLLD2 is as main HDMI clock parent.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
With each new SoC added to the clock_sun50i_h6.h header file, we add a
list of default values for the bus clock registers. This list gets a bit
hard to read, as the spacing between the lines looks confusing.
Tighten the lines by removing empty lines, to make it more obvious which
values belong together. Also remove those comments that were more or
less duplicating the next code line, and didn't add any information.
This makes it easier to find existing values and to add support for new
SoCs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Add MIDR entries for Cortex-A57 and Cortex-A76 cores.
Those are used on R-Car Gen3 and Gen4 SoCs respectively.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Turn the core type check macros into inline functions to perform
better type checking on them. The inline functions get optimized
out in case they are not used. Indent the MIDR_PARTNUM_CORTEX_An
macros in preparation for addition of future three-digit cores
and use MIDR_PARTNUM_SHIFT in MIDR_PARTNUM_MASK to be consistent.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The mask for aclk_vop_root is 3-bit wide, not 2-bit wide according
to the TRM, so set the mask accordingly.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Drop global ddrphy_trained_csr which maybe different with per board
ddrphy_trained_csr. DDR TOOL generates ddrphy_trained_csr for each
board, using the global ddrphy_trained_csr has risk that values may
be not up to date.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
