<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git, branch v2026.04-rc1</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>Prepare v2026.04-rc1</title>
<updated>2026-01-26T20:44:52+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-26T20:44:52+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=aa4f687977a449686498236722ee5e93d8b39918'/>
<id>aa4f687977a449686498236722ee5e93d8b39918</id>
<content type='text'>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>count rel_dyn</title>
<updated>2026-01-26T17:19:22+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-26T17:19:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dc2d8423b19d30472b02e02b41504226908a4291'/>
<id>dc2d8423b19d30472b02e02b41504226908a4291</id>
<content type='text'>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "arm: spl: Correct alignment of .rel.dyn section"</title>
<updated>2026-01-26T17:00:02+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-26T17:00:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f4dfa5d3c2680322fd17fcc7c6221876e00a03c2'/>
<id>f4dfa5d3c2680322fd17fcc7c6221876e00a03c2</id>
<content type='text'>
This reverts commit 380ddb473c6bdf87e66c0fb93e256d1e233c6f5b.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 380ddb473c6bdf87e66c0fb93e256d1e233c6f5b.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: spl: Correct alignment of .rel.dyn section</title>
<updated>2026-01-26T16:46:23+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-26T16:28:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=380ddb473c6bdf87e66c0fb93e256d1e233c6f5b'/>
<id>380ddb473c6bdf87e66c0fb93e256d1e233c6f5b</id>
<content type='text'>
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") we now require the correct, 8 byte alignment
of a device tree in order to work with it ourselves. This has exposed a
number of issues. In the case of using arch/arm/cpu/u-boot-spl.lds for
an xPL phase and having the BSS be overlayed with the dynamic
relocations sections (here, .rel.dyn) we had missed adding the comment
about our asm memset requirements. Then, when adjusting ALIGN statements
we later missed this one. In turn, when we use objcopy to create our
binary image we end up in the situation where

where the BSS must start out 8 byte aligned as
well as end 8 byte aligned because for appended device tree the
requirement is that the whole BSS (which we add as padding to the
binary) must be 8 byte aligned. Otherwise we end up with the situation
where __bss_end (where we look for the device tree at run time) is
aligned but the size of the BSS we add

Fixes: 7828a1eeb2a1 ("arm: remove redundant section alignments")
Fixes: 52caad0d14a3 ("ARM: Align image end to 8 bytes to fit DT alignment")
Reported-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Tested-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
---
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Marek Vasut &lt;marek.vasut@mailbox.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") we now require the correct, 8 byte alignment
of a device tree in order to work with it ourselves. This has exposed a
number of issues. In the case of using arch/arm/cpu/u-boot-spl.lds for
an xPL phase and having the BSS be overlayed with the dynamic
relocations sections (here, .rel.dyn) we had missed adding the comment
about our asm memset requirements. Then, when adjusting ALIGN statements
we later missed this one. In turn, when we use objcopy to create our
binary image we end up in the situation where

where the BSS must start out 8 byte aligned as
well as end 8 byte aligned because for appended device tree the
requirement is that the whole BSS (which we add as padding to the
binary) must be 8 byte aligned. Otherwise we end up with the situation
where __bss_end (where we look for the device tree at run time) is
aligned but the size of the BSS we add

Fixes: 7828a1eeb2a1 ("arm: remove redundant section alignments")
Fixes: 52caad0d14a3 ("ARM: Align image end to 8 bytes to fit DT alignment")
Reported-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Tested-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
---
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Marek Vasut &lt;marek.vasut@mailbox.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi</title>
<updated>2026-01-26T15:09:16+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-26T15:09:16+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c08da5d03c2a0b72e81a11ff7ca507e3a6414db3'/>
<id>c08da5d03c2a0b72e81a11ff7ca507e3a6414db3</id>
<content type='text'>
Some improvements for some boards' DRAM setup, to allow boards with
"odd" DRAM sizes (1.5GB or 3GB), and to support the T113-s4 with double
the co-packaged DRAM. Support for a new board (X96Q TV box), and a fix
for the DT name prefix. Also we support the new AXP318W PMIC, which is
used on new boards with the A733 SoC. There are some preliminary support
patches for this SoC, but they are not quite ready yet - though maybe I
push some uncontroversial ones a bit later still.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some improvements for some boards' DRAM setup, to allow boards with
"odd" DRAM sizes (1.5GB or 3GB), and to support the T113-s4 with double
the co-packaged DRAM. Support for a new board (X96Q TV box), and a fix
for the DT name prefix. Also we support the new AXP318W PMIC, which is
used on new boards with the A733 SoC. There are some preliminary support
patches for this SoC, but they are not quite ready yet - though maybe I
push some uncontroversial ones a bit later still.
</pre>
</div>
</content>
</entry>
<entry>
<title>board: sunxi: Add X96Q support</title>
<updated>2026-01-25T23:29:32+00:00</updated>
<author>
<name>J. Neuschäfer</name>
<email>j.ne@posteo.net</email>
</author>
<published>2026-01-20T15:20:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8805aa120ca5341ca14d8f7f2311f7a85d57a5f9'/>
<id>8805aa120ca5341ca14d8f7f2311f7a85d57a5f9</id>
<content type='text'>
The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
output, and infrared input.

  https://x96mini.com/products/x96q-tv-box-android-10-set-top-box

This commit adds a defconfig and some documentation. The devicetree is
already in dts/upstream.

The CONFIG_DRAM_SUNXI_* settings are chosen such that the register
values in the DRAM PHY's MMIO space are as close as possible to those
observed when booting with the preinstalled vendor U-Boot. The DRAM
clock frequency of 600 MHz was reported in the vendor U-Boot's output.

Signed-off-by: J. Neuschäfer &lt;j.ne@posteo.net&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
output, and infrared input.

  https://x96mini.com/products/x96q-tv-box-android-10-set-top-box

This commit adds a defconfig and some documentation. The devicetree is
already in dts/upstream.

The CONFIG_DRAM_SUNXI_* settings are chosen such that the register
values in the DRAM PHY's MMIO space are as close as possible to those
observed when booting with the preinstalled vendor U-Boot. The DRAM
clock frequency of 600 MHz was reported in the vendor U-Boot's output.

Signed-off-by: J. Neuschäfer &lt;j.ne@posteo.net&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>power: regulator: enable AWP318W SPL support</title>
<updated>2026-01-25T23:29:32+00:00</updated>
<author>
<name>Yixun Lan</name>
<email>dlan@gentoo.org</email>
</author>
<published>2026-01-13T04:01:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=61c2f29bde1d11a35664525d37c5806e61ec4304'/>
<id>61c2f29bde1d11a35664525d37c5806e61ec4304</id>
<content type='text'>
Add the descriptions for the DC/DC regulators of the AXP318W, and enable
it when CONFIG_AXP318W_POWER is enabled.

Signed-off-by: Yixun Lan &lt;dlan@gentoo.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the descriptions for the DC/DC regulators of the AXP318W, and enable
it when CONFIG_AXP318W_POWER is enabled.

Signed-off-by: Yixun Lan &lt;dlan@gentoo.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>power: regulator: add AXP318W support</title>
<updated>2026-01-25T23:29:32+00:00</updated>
<author>
<name>Yixun Lan</name>
<email>dlan@gentoo.org</email>
</author>
<published>2026-01-13T04:01:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=71f07932756fa9f414146618c02ed299d565f092'/>
<id>71f07932756fa9f414146618c02ed299d565f092</id>
<content type='text'>
The PMIC is also known as AXP819 in vendor pmu code

For DCDC6, 8, 9, the underlying hardware support more than two levels
voltage step tuning, but for now only first two levels are implemented
in this driver, hence highest voltage will be limited at seccond level.
It actual meets board requirement in current design, and we've verified
it in Radxa Cubie A7A board.

Following are detail explanation of voltage tuning stpes for those DCDCs:

DCDC | voltage range  | units | steps | implemented
 6   | 0.5   -  1.2   | 10 mV | 71    | Y
 .   | 1.22  -  1.54  | 20 mV | 17    | Y
 .   | 1.8   -  2.4   | 20 mV | 31    | N
 .   | 2.44  -  2.76  | 40 mV | 9     | N
 --------------------------------------------------
 8/9 | 0.5   -  1.2   | 10 mV | 71    | Y
 .   | 1.22  -  1.84  | 20 mV | 32    | Y
 .   | 1.9   -  3.4   | 100mV | 16    | N

Signed-off-by: Yixun Lan &lt;dlan@gentoo.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The PMIC is also known as AXP819 in vendor pmu code

For DCDC6, 8, 9, the underlying hardware support more than two levels
voltage step tuning, but for now only first two levels are implemented
in this driver, hence highest voltage will be limited at seccond level.
It actual meets board requirement in current design, and we've verified
it in Radxa Cubie A7A board.

Following are detail explanation of voltage tuning stpes for those DCDCs:

DCDC | voltage range  | units | steps | implemented
 6   | 0.5   -  1.2   | 10 mV | 71    | Y
 .   | 1.22  -  1.54  | 20 mV | 17    | Y
 .   | 1.8   -  2.4   | 20 mV | 31    | N
 .   | 2.44  -  2.76  | 40 mV | 9     | N
 --------------------------------------------------
 8/9 | 0.5   -  1.2   | 10 mV | 71    | Y
 .   | 1.22  -  1.84  | 20 mV | 32    | Y
 .   | 1.9   -  3.4   | 100mV | 16    | N

Signed-off-by: Yixun Lan &lt;dlan@gentoo.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sunxi: avoid double vendor prefix when CONFIG_OF_UPSTREAM is enabled</title>
<updated>2026-01-25T23:29:32+00:00</updated>
<author>
<name>Bohdan Chubuk</name>
<email>chbgdn@gmail.com</email>
</author>
<published>2025-11-23T20:43:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=eb7390797d262eaab589a4d4e71fbb0c156bd61c'/>
<id>eb7390797d262eaab589a4d4e71fbb0c156bd61c</id>
<content type='text'>
When CONFIG_OF_UPSTREAM is enabled, the device tree name provided by SPL
already includes the vendor directory (e.g., "allwinner/board-name").

The existing logic in misc_init_r() unconditionally prepends "allwinner/"
for ARM64 builds, resulting in an incorrect path like
"allwinner/allwinner/board-name.dtb".

This patch modifies the logic to only prepend the vendor prefix if
CONFIG_OF_UPSTREAM is NOT enabled. This ensures compatibility with both
legacy builds and the new upstream devicetree structure.

Signed-off-by: Bohdan Chubuk &lt;chbgdn@gmail.com&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When CONFIG_OF_UPSTREAM is enabled, the device tree name provided by SPL
already includes the vendor directory (e.g., "allwinner/board-name").

The existing logic in misc_init_r() unconditionally prepends "allwinner/"
for ARM64 builds, resulting in an incorrect path like
"allwinner/allwinner/board-name.dtb".

This patch modifies the logic to only prepend the vendor prefix if
CONFIG_OF_UPSTREAM is NOT enabled. This ensures compatibility with both
legacy builds and the new upstream devicetree structure.

Signed-off-by: Bohdan Chubuk &lt;chbgdn@gmail.com&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sunxi: dram: detect non-power-of-2 sized DRAM chips</title>
<updated>2026-01-25T23:29:32+00:00</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2025-10-21T23:53:34+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c47b636737366d9bc017b915ca6fcbcce8706e6e'/>
<id>c47b636737366d9bc017b915ca6fcbcce8706e6e</id>
<content type='text'>
Some boards feature an "odd" DRAM size, where the total RAM is 1.5GB or
3GB. Our existing DRAM size detection routines can only detect power-of-2
sized configuration, and on those boards the DRAM size is overestimated,
so this typically breaks the boot quite early.

There doesn't seem to be an easy explicit way to detect those odd-sized
chips, but we can test whether the later part of the memory behaves like
memory, by verifying that a written pattern can be read back.
Experiments show that there is no aliasing effect here, as all locations
in the unimplemented range always return some fixed pattern, and cannot
be changed.

Also so far all those boards use a factor of 3 of some lower power-of-2
number, or 3/4th of some higher number. The size detection routine
discovers the higher number, so we can check for some memory cells beyond
75% of the detected size to be legit.

Add a routine the inverts all bits at a given location in memory, and
reads that back to prove that the new value was stored.
Then test the memory cell at exactly 3/4th of the detected size, and cap
the size of the memory to 75% when this test fails. For good measure
also make sure that memory just below the assumed memory end really
works.

This enables boards which ship with such odd memory sizes.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Reviewed-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some boards feature an "odd" DRAM size, where the total RAM is 1.5GB or
3GB. Our existing DRAM size detection routines can only detect power-of-2
sized configuration, and on those boards the DRAM size is overestimated,
so this typically breaks the boot quite early.

There doesn't seem to be an easy explicit way to detect those odd-sized
chips, but we can test whether the later part of the memory behaves like
memory, by verifying that a written pattern can be read back.
Experiments show that there is no aliasing effect here, as all locations
in the unimplemented range always return some fixed pattern, and cannot
be changed.

Also so far all those boards use a factor of 3 of some lower power-of-2
number, or 3/4th of some higher number. The size detection routine
discovers the higher number, so we can check for some memory cells beyond
75% of the detected size to be legit.

Add a routine the inverts all bits at a given location in memory, and
reads that back to prove that the new value was stored.
Then test the memory cell at exactly 3/4th of the detected size, and cap
the size of the memory to 75% when this test fails. For good measure
also make sure that memory just below the assumed memory end really
works.

This enables boards which ship with such odd memory sizes.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Reviewed-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
