<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/arm/lib/Makefile, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>Merge patch series "ARM: bootm: Add support for starting Linux through OPTEE-OS on ARMv7a"</title>
<updated>2025-11-06T19:35:51+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-11-06T17:32:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ad9240cb9df25fa9059c32dea7b4d739525e76f2'/>
<id>ad9240cb9df25fa9059c32dea7b4d739525e76f2</id>
<content type='text'>
This series from Marek Vasut &lt;marek.vasut@mailbox.org&gt; brings some
enhancements to use cases using OPTEE-OS on ARMv7a platforms, some of
which already existed on ARMv8.

Link: https://lore.kernel.org/r/20251030212359.12824-1-marek.vasut@mailbox.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This series from Marek Vasut &lt;marek.vasut@mailbox.org&gt; brings some
enhancements to use cases using OPTEE-OS on ARMv7a platforms, some of
which already existed on ARMv8.

Link: https://lore.kernel.org/r/20251030212359.12824-1-marek.vasut@mailbox.org
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: bootm: Add support for starting Linux through OPTEE-OS on ARMv7a</title>
<updated>2025-11-06T17:26:18+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut@mailbox.org</email>
</author>
<published>2025-10-30T21:23:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=20861863eb3010581b12e9a77eb7958460edaa82'/>
<id>20861863eb3010581b12e9a77eb7958460edaa82</id>
<content type='text'>
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a.
This is only supported if U-Boot runs in PL1 secure. This change adds
two components, one is fitImage OPTEE-OS loadable handler, which makes
a note of OPTEE-OS being loaded and stores the load address for later
jump to it. The second part is the actual jump to Linux through OPTEE-OS.
The jump through OPTEE-OS requires set up of multiple CPU registers, r1
and r2 are passed through, r0 and r3 have to be set to 0, lr is set to
Linux kernel entry point. This setup is done by new assembler function
boot_jump_linux_via_optee().

The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC
configuration write, this cannot be moved easily, hence the ifdef.

Signed-off-by: Marek Vasut &lt;marek.vasut@mailbox.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a.
This is only supported if U-Boot runs in PL1 secure. This change adds
two components, one is fitImage OPTEE-OS loadable handler, which makes
a note of OPTEE-OS being loaded and stores the load address for later
jump to it. The second part is the actual jump to Linux through OPTEE-OS.
The jump through OPTEE-OS requires set up of multiple CPU registers, r1
and r2 are passed through, r0 and r3 have to be set to 0, lr is set to
Linux kernel entry point. This setup is done by new assembler function
boot_jump_linux_via_optee().

The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC
configuration write, this cannot be moved easily, hence the ifdef.

Signed-off-by: Marek Vasut &lt;marek.vasut@mailbox.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spl: remove usage of CMD_BOOTx from image parsing</title>
<updated>2025-11-03T17:52:05+00:00</updated>
<author>
<name>Anshul Dalal</name>
<email>anshuld@ti.com</email>
</author>
<published>2025-10-27T14:17:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=823e453987a6590af67e2226ad3e73fb399c205d'/>
<id>823e453987a6590af67e2226ad3e73fb399c205d</id>
<content type='text'>
Using CMD_* configs from spl doesn't make logical sense. Therefore
this patch replaces the checks for CMD_BOOTx with newly added library
symbols LIB_BOOT[IMZ] and SPL_LIB_BOOT[IMZ] which are enabled by their
respective CMD_* or SPL_* counterparts.

On platforms with non-secure falcon mode, SPL_BOOTZ is enabled by
default for 32-bit ARM systems and SPL_BOOTI is enabled by default for
64-bit ARM and RISCV.

The respective C files (image.c/zimage.c) are compiled based on library
symbols $(PHASE_)LIB_BOOTx instead which are in turn selected by both
CMD_BOOTx and SPL_BOOTx as required.

Signed-off-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Using CMD_* configs from spl doesn't make logical sense. Therefore
this patch replaces the checks for CMD_BOOTx with newly added library
symbols LIB_BOOT[IMZ] and SPL_LIB_BOOT[IMZ] which are enabled by their
respective CMD_* or SPL_* counterparts.

On platforms with non-secure falcon mode, SPL_BOOTZ is enabled by
default for 32-bit ARM systems and SPL_BOOTI is enabled by default for
64-bit ARM and RISCV.

The respective C files (image.c/zimage.c) are compiled based on library
symbols $(PHASE_)LIB_BOOTx instead which are in turn selected by both
CMD_BOOTx and SPL_BOOTx as required.

Signed-off-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "Switch to using $(PHASE_) in Makefiles"</title>
<updated>2025-04-11T18:16:49+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-04-11T18:16:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=407d68638fe32418d61681407effba2a303bb9ee'/>
<id>407d68638fe32418d61681407effba2a303bb9ee</id>
<content type='text'>
Tom Rini &lt;trini@konsulko.com&gt; 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/20250401225851.1125678-1-trini@konsulko.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Tom Rini &lt;trini@konsulko.com&gt; 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/20250401225851.1125678-1-trini@konsulko.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Kbuild: Always use $(PHASE_)</title>
<updated>2025-04-11T18:16:44+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-04-01T22:55:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=302b41d5397e9f821d360a74335e8821d4513970'/>
<id>302b41d5397e9f821d360a74335e8821d4513970</id>
<content type='text'>
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 &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: Exclude eabi_compat from LTO</title>
<updated>2025-04-02T20:33:50+00:00</updated>
<author>
<name>Sam Edwards</name>
<email>cfsworks@gmail.com</email>
</author>
<published>2025-03-15T22:18:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6ba839a0f5473aac8dc038f8601071234c810119'/>
<id>6ba839a0f5473aac8dc038f8601071234c810119</id>
<content type='text'>
These symbols need to survive the IR-level dead function elimination pass,
since nothing at the IR level is referencing them (calls to these are inserted
later, at codegen time).

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Acked-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These symbols need to survive the IR-level dead function elimination pass,
since nothing at the IR level is referencing them (calls to these are inserted
later, at codegen time).

Signed-off-by: Sam Edwards &lt;CFSworks@gmail.com&gt;
Acked-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "Implement ACPI on aarch64"</title>
<updated>2024-10-28T00:44:13+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-10-27T23:14:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2800aecce08b47b169d8e9824dd23b1297b2cedc'/>
<id>2800aecce08b47b169d8e9824dd23b1297b2cedc</id>
<content type='text'>
Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt; says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt; says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: lib: Add GICV2 driver</title>
<updated>2024-10-27T23:24:13+00:00</updated>
<author>
<name>Patrick Rudolph</name>
<email>patrick.rudolph@9elements.com</email>
</author>
<published>2024-10-23T13:20:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=df8d759d9db17b55d6283a9a1d84d196e9cc1dd4'/>
<id>df8d759d9db17b55d6283a9a1d84d196e9cc1dd4</id>
<content type='text'>
Add a generic GICV2 driver that:
- parses the DT and generates the ACPI MADT subtables
- implement of_xlate() and allows irq_get_by_index() to return the
  correct interrupt mappings

Map DT interrupts to ARM GIC interrupts	as follows:

- Interrupt numbers ID32-ID1019 are used for SPIs
- ID0-ID15 are used for SGIs
- ID16-ID31 are used for PPIs

TEST: Booted on QEMU raspb4 using GICV2 driver model generated MADT.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a generic GICV2 driver that:
- parses the DT and generates the ACPI MADT subtables
- implement of_xlate() and allows irq_get_by_index() to return the
  correct interrupt mappings

Map DT interrupts to ARM GIC interrupts	as follows:

- Interrupt numbers ID32-ID1019 are used for SPIs
- ID0-ID15 are used for SGIs
- ID16-ID31 are used for PPIs

TEST: Booted on QEMU raspb4 using GICV2 driver model generated MADT.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: acpi: Add generic ACPI methods</title>
<updated>2024-10-27T23:24:13+00:00</updated>
<author>
<name>Patrick Rudolph</name>
<email>patrick.rudolph@9elements.com</email>
</author>
<published>2024-10-23T13:19:50+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f36e29e8da2f1b4a776b157e5f6c8368546da803'/>
<id>f36e29e8da2f1b4a776b157e5f6c8368546da803</id>
<content type='text'>
Add generic ACPI code to generate
- MADT GICC
- MADT GICD
- MADT GICR
- MADT GIC ITS
- PPTT processor
- PPTT cache

as commonly used on arm platforms.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add generic ACPI code to generate
- MADT GICC
- MADT GICD
- MADT GICR
- MADT GIC ITS
- PPTT processor
- PPTT cache

as commonly used on arm platforms.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"</title>
<updated>2024-10-11T18:23:25+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-10-11T18:23:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=47e544f576699ca4630e20448db6a05178960697'/>
<id>47e544f576699ca4630e20448db6a05178960697</id>
<content type='text'>
Simon Glass &lt;sjg@chromium.org&gt; says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) &amp;&amp; !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Simon Glass &lt;sjg@chromium.org&gt; says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) &amp;&amp; !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
</pre>
</div>
</content>
</entry>
</feed>
