| Age | Commit message (Collapse) | Author |
|---|
|
Jerome Forissier <[email protected]> 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/[email protected]
|
|
Change board_init_f(), board_init_f_r() and board_init_r() to make
static calls instead of iterating over the init_sequence_f,
init_sequence_f_r and init_sequence_r arrays, respectively. This makes
the code a simpler (and even more so when initcall_run_list() is
later removed) and it reduces the binary size as well. Tested with
xilinx_zynqmp_kria_defconfig; bloat-o-meter results:
- With LTO
add/remove: 106/196 grow/shrink: 10/28 up/down: 31548/-33829 (-2281)
Total: Before=1070471, After=1068190, chg -0.21%
- Without LTO
add/remove: 0/54 grow/shrink: 3/0 up/down: 2322/-2832 (-510)
Total: Before=1121723, After=1121213, chg -0.05%
Execution time does not change in a noticeable way.
Signed-off-by: Jerome Forissier <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Svyatoslav Ryhel <[email protected]>
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
The Tegra Note 7 is a mini tablet computer and the second Tegra 4
based mobile device designed by Nvidia that runs the Android operating
system. The Tegra Note has a 7" IPS display with 1280 x 800 (217 ppi)
resolution. The 1 GB of RAM and 16 GB of internal memory can be
supplemented with a microSDXC card giving up to 64 GB of additional
storage.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
The ASUS Transformer Pad TF701T is an Android tablet computer made by
ASUS, successor to the ASUS Transformer Pad Infinity. The tablet includes
a Tegra 4 T114 processor clocked at 1.9 GHz, and an upgraded 2560×1600
pixel resolution screen, increasing the pixel density to 300 PPI and
a mobile dock. Transformers (t114) board derives from Nvidia Macallan
development board.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
The clock initialization routine sets the DISP* clock parent to PLLC,
resulting in DC failure in the case when PLLD was previously configured.
This issue disrupts chainloading and to prevent failures caused by DISP*
clock parent conflicts, clock initialization should not modify DISP*. The
DC driver handles DISP* configuration.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Convert CFG_TEGRA_BOARD_STRING into Kconfig option and move it into device
board Kconfig.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Link CFG_SYS_NS16550_COM1 value to chosen CONFIG_TEGRA_ENABLE_UART Tegra
wide. Remove all CFG_SYS_NS16550_COM1 from device headers.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
The Motorola Atrix 4G (MB860) and Droid X2 (MB870) both featured a
dual-core NVIDIA Tegra 2 AP20H processor clocked at 1GHz, coupled with 1GB
of DDR2 RAM. Storage consisted of 16GB of internal flash memory, expandable
via microSD. The display was a 4.0-inch TFT LCD with a resolution of
960x540 pixels (qHD). The devices originally ran on Android up to 2.3
(Gingerbread).
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Historically, PLLD2 mirrored PLLD's layout on Tegra30 and 114. However,
with the introduction of Tegra124, this changed. This layout alteration was
not considered, and it now requires a corrective action to prevent future
complications.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
PLLD and PLLD2 clocks possess a unique enable bit within their
miscellaneous register. Take this into account when using clock_set_rate
function.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Tom Rini <[email protected]> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/[email protected]
|
|
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-snapdragon
Qualcomm changes for v2025.07:
CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/25653
There's been a surprising amount of activity lately on the Qualcomm
side with the two oldest boards getting some fresh attention and a lot
of cleanup and polish going on across the board.
* SDM660 gets USB phy fixes and a pinctrl driver
* The recently added SA8775P/QCS9100 SoC gets a pinctrl driver
* The Qualcomm pinctrl driver now handles reserved pins correctly,
fixing crashes on some boards when running "gpio status -a"
* OF_UPSTREAM_BUILD_VENDOR is enabled in qcom_defconfig
* SDM845 and SC7280 get missing clocks added (since we're now stricter
about those). This gets USB working more reliably in more cases.
* DM_USB_GADGET is enabled for all boards using DWC3 and fasbtoot is
enabled too
* A bug in the livetree fixup code is fixed (making USB work on a lot
more platforms)
* Button label lookup is made case insensitive* bootretry becomes more dynamic, allowing it to be hijacked to make a
"persistent" boot menu that allows dropping to U-Boot shell later on
* A new qcom-phone.config fragment is added along with a phone-specific
default environment and phone-specific debugging/bringup docs. These
make U-Boot more usable on devices without a serial port or keyboard.
* The db820c gets fixed up and updated documentation
* The db410c also gets some love and modernisation as well as a new
reviewer.
* A new driver is added for the USB VBUS regulator found on various
Qualcomm PMICs
* The Qualcomm SPMI driver gets some fixes and cleanup for SPMI v5 and
v7 support.
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/25652
- Add i.MX8MP LDB support.
- Various phycore-imx93 environment improvements.
- Add support for Toradex SMARC iMX8MP.
|
|
DB410c has exactly 1 GiB of RAM. Some of it is reserved, but this is
described separately in the DT.
This was fixed before in commit 1d667227ea51 ("board: dragonboard410c: Fix
PHYS_SDRAM_1_SIZE"), but was reintroduced when DB410c was converted to use
the upstream device tree.
Note that there are variants of apq8016-sbc with 2 GiB RAM (e.g. the
Geniatech DB4). They need the WIP SMEM memory map parsing [1] to use the
full amount of RAM.
[1]: https://lore.kernel.org/u-boot/[email protected]/T/
Fixes: ed8fbd2889fc ("dts: msm8916: replace with upstream DTS")
Signed-off-by: Stephan Gerhold <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by:
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Caleb Connolly <[email protected]>
|
|
The workaround for the "PSCI bug" on DragonBoard 410c implemented in
arch/arm/mach-snapdragon/include/mach/boot0.h clobbers the x0 register
by storing the CurrentEL in there. When running in EL1, the mode switch
sequence implemented there later clears the register again, but this is
skipped when U-Boot is booted in EL2.
This causes crashes in the mach-snapdragon board_fdt_blob_setup() later,
because the invalid address stored in x0 gets dereferenced to check if it
points to a valid DTB.
We can't rely on having a valid values in the CPU registers for the first
stage bootloader configuration on DB410c, and nothing would place a DTB
there anyway. Skip selecting the SAVE_PREV_BL_FDT_ADDR option for the boot0
hook case to avoid crashing with the clobbered register value.
Fixes: 059d526af312 ("mach-snapdragon: generalise board support")
Signed-off-by: Stephan Gerhold <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by:
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Some Qualcomm boards feature reserved ranges of pins which are protected
by firmware. Attempting to read or write any registers associated with
these pins results the board resetting.
Add support for parsing these ranges from devicetree and ensure that the
pinctrl and GPIO drivers don't try to interact with these pins.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Link: https://lore.kernel.org/r/20250410-topic-sm8x50-pinctrl-reserved-ranges-v2-1-654488392b9a@linaro.org
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add support for the Toradex SMARC iMX8MP.
Link: https://www.toradex.com/computer-on-modules/smarc-arm-family/nxp-imx-8m-plus
Link: https://www.toradex.com/products/carrier-board/smarc-development-board-kit
Signed-off-by: Vitor Soares <[email protected]>
|
|
Sync imx8mp.dtsi with Linux v6.15-rc1.
Signed-off-by: Vitor Soares <[email protected]>
|
|
As current design, only Manager CPU called armv8_setup_psci() before
jump to next stage(such as Linux Kernel), Subordinate CPUs also need
setup psci vector to handle trap request which comes from higher EL
level.
Signed-off-by: Xu Zhang <[email protected]>
[trini: Guard with !CONFIG_XPL_BUILD check]
|
|
SoMs ***"
Wadim Egorov <[email protected]> says:
Add general ethernet boot support for AM62Ax SoC.
Some of the work is based on TI's downstream u-boot patches found in
[1], patches touching code in mach-k3 and *.yaml board config files.
Also, provide defconfigs and device tree changes for phyCORE-AM62x and
phyCORE-AM62Ax to support booting via ethernet.
[1] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1307981/sk-am62a-lp-rgmii-boot-mode-problem
Link: https://lore.kernel.org/r/[email protected]
|
|
This data was generated using the ksswtool-autogen project with the
followig commit:
eed7492 ("soc: am62ax: Add cpsw_3guss_main_0 id to the dev list")
Signed-off-by: Andreas Dannenberg <[email protected]>
Signed-off-by: Nathan Morrisson <[email protected]>
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Probe CPSW NUSS in am62a7 board_init_f() to support ethernet boot.
Signed-off-by: Nathan Morrisson <[email protected]>
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Don't initialize Ethernet2 in SPL. We cannot boot from that source anyways
and it throws an error during boot.
This will remove following error message during network boot:
Error: ethernet@8000000port@2 No valid MAC address found.ethernet@8000000port@1
Waiting for PHY auto negotiation to complete....... done
Signed-off-by: Daniel Schultz <[email protected]>
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Add bootph-all tag to phy_gmii_sel node. This is needed for booting via
Ethernet. While at it, drop main_pktdma reg redefinitions which are already
provided by the top-level SoC device tree file.
Signed-off-by: Wadim Egorov <[email protected]>
Tested-by: Daniel Schultz <[email protected]>
|
|
The fdt_node_check_compatible() function returns 0 on success which is
pretty confusing, and we were using it wrong!
Invert the condition check and refactor things to be more readable.
Additionally, add the check for the RB1 which needs the same fixup as
the RB2.
Reported-by: Sam Day <[email protected]>
Fixes: e64503f1fcdf ("mach-snapdragon: implement ft_board_setup() for USB role selection")
Tested-by: Alexey Minnekhanov <[email protected]>
Tested-by: Sam Day <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Caleb Connolly <[email protected]>
|
|
The length of a property includes '\0' in a string type one, so
the length passed by needs to have that in account, if not,
when getting the property value it will fail because it
has the wrong size.
Signed-off-by: Rui Miguel Silva <[email protected]>
Tested-by: [email protected] # db845c
Reviewed-by: Caleb Connolly <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Caleb Connolly <[email protected]>
|
|
This is required for gadget modes to work on most platforms. It must be
disabled for dragonboard410c since that doesn't use dwc3. USB on other
MSM8916 platforms isn't supported by qcom_defconfig anyway.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Compared to SAM9X5 the only difference is the DPRAM memory from the
USB High Speed Device Port (UDPHS) hardware block was increased,
so we can reuse the same endpoint data.
Also add compatible "microchip,sam9x60-udc".
Signed-off-by: Zixun LI <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Andre Przywara <[email protected]> says:
C's implicit fallthrough behaviour in switch/case statements can lead to
subtle bugs. Quite some while ago many compilers introduced warnings in
those cases, requiring intentional fallthrough's to be annotated.
So far we were not enabling that compiler option, so many ambiguities
and some bugs in the code went unnoticed.
This series adds the required annotations in code paths that the first
stage of the U-Boot CI covers. There is a large number of cases left
in the libbz2 code. The usage of switch/case is borderline insane there,
labels are hidden in macros, and there are no breaks, but just goto's.
Upstream still uses very similar code, without any annotations. I still
am not 100% sure those are meant to fall through or not, and plan to do
further investigations, but didn't want to hold the rest of the patches
back. You can see for yourself by applying patch 18/18 and building for
sandbox64, for instance.
Because of this we cannot quite enable the warning in the Makefile yet,
but those fixes are worth regardless, and be it to increase readability.
Please note that those patches do not fix anything, really, they just add
those fallthrough annotations, so the series is not really critical.
Link: https://lore.kernel.org/r/[email protected]
|
|
The MMC boot mode selection for the TI AM62P series of SoCs uses an
implicit switch/case fallthrough for falling back to some default
boot mode.
Add our "fallthrough;" statement-like macro before the default branch in
the code, to avoid a warning when GCC's -Wimplicit-fallthrough warning
option is enabled.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Heinrich Schuchardt <[email protected]> says:
Introduce a new function to update ACPI table headers.
This allows to simplify the existing code.
Link: https://lore.kernel.org/r/[email protected]
|
|
According to the binding [1] the ITS node should be a subnode of the
GICv3 node. Thus move it now that the driver binds subnodes as well.
1: https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic-v3.txt
Signed-off-by: Patrick Rudolph <[email protected]>
|
|
According to the binding [1] the ITS node should be a subnode of the
GICv3 node. Since the ITS node has it's own driver, manually probe for
possible subnodes after binding since dm_scan_fdt() is not recursive.
1: https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic-v3.txt
Signed-off-by: Patrick Rudolph <[email protected]>
|
|
Use acpi_update_checksum() to update table header.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
Use acpi_update_checksum() for updating ACPI table header checksum.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
in extlinux / PXE""
This reverts commit 8bc3542384e3a1219e5ffb62b79d16dddc1b1fb9, reversing
changes made to 698edd63eca090a2e299cd3facf90a0b97bed677.
There are still problems with this series to work out.
Link: https://lore.kernel.org/u-boot/CAFLszTjw_MJbK9tpzVYi3XKGazcv55auBAdgVzcAVUta7dRqcg@mail.gmail.com/
Signed-off-by: Tom Rini <[email protected]>
|
|
Include spl.h to avoid definition errors in custom builds.
Fixes: commit bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled")
Signed-off-by: Neha Malcom Francis <[email protected]>
|
|
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 <[email protected]>
|
|
The file k3-am62a7.dtsi is part of upstream DT and should
have been removed when migrating to OF_UPSTREAM but must
have been missed. Do this here.
Signed-off-by: Andrew Davis <[email protected]>
|
|
Correct the preprocessor directive used to check for 64-bit kernel
support in the `zboot_go` function. The code previously checked for
`CONFIG_X86_RUN_64BIT`, which is not the correct configuration option
for determining if the kernel should run in 64-bit mode. The correct
option is `CONFIG_X86_64`.
Signed-off-by: Jeremy Compostella <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
As both CONFIG_X86_RUN_64BIT and X86_RUN_64BIT_NO_SPL cases run U-Boot
in 64-bit mode with the CPU fully initialized already.
Signed-off-by: Jeremy Compostella <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This commit introduces a new configuration option X86_RUN_64BIT_NO_SPL
to allow building U-Boot as a 64-bit binary without using the SPL
(Secondary Program Loader). The motivation is to simplify the boot
process for certain x86-based platforms that do not require SPL, such as
those booting directly from a 64-bit coreboot firmware.
This update revises the `X86_RUN_64BIT` configuration to more accurately
describe its role as "32-bit SPL followed by 64-bit U-Boot." It
clarifies the sequence of operations during the boot process, where the
system transitions from a 32-bit SPL (Secondary Program Loader) to the
main 64-bit U-Boot.
Signed-off-by: Jeremy Compostella <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
We currently set both and print both PXN and UXN bits when removing
execution for pages. This happens even in the existing per platform
definitions of 'struct mm_region'.
That's not entirely correct though. For stage-1 translations, if a
platform runs on a translation regime with a single privilege level or the
the translation regime supports two privilege levels and we are not
in EL1&0 with HCR_EL2.{NV, NV1} = {1, 1} only BIT54 (XN) is needed
and BIT53(PXN) is reserved 0.
Currently we support Non-Secure EL2, Non-secure EL2&0 and Non-secure
EL1&0.
We already have get_effective_el() which returns 1 if we are
- Running in EL1 so we assume an EL1 translation regime but without
checking HCR_EL2.{NV, NV1} != {1,1}
- Running in EL2 with HCR_EL2.E2H = 1
The only problem with the above is that if we are in EL1&0 and
HCR_EL2.{NV1, NV} == {1, 1}, then
- Bit[54] holds the PXN instead of the UXN
- The Effective value of UXN is 0
- Bit[53] is RES0
So let's re-use that function and set PXN only when we are in
and EL[2|1]&0 translation regime.
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
empty/full"
Simon Glass <[email protected]> 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/[email protected]
|
|
Rename the struct to match the function prefix and filenames.
Signed-off-by: Simon Glass <[email protected]>
|
|
Simon Glass <[email protected]> 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/[email protected]/
|
|
Add some missing pieces to bootparams so that a 64-bit ramdisk address
can be used. Tidy up the logging while we are here.
Signed-off-by: Simon Glass <[email protected]>
|
