<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/arm/include, branch v2026.04</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/arch/arm/include?h=v2026.04</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/arch/arm/include?h=v2026.04'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2026-03-23T06:27:24Z</updated>
<entry>
<title>armv7: ls102xa: fix SPI flash clock</title>
<updated>2026-03-23T06:27:24Z</updated>
<author>
<name>Michael Walle</name>
<email>mwalle@kernel.org</email>
</author>
<published>2026-03-18T14:29:17Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1f305f99d2001e96daa7e93da4da2bf56da9278e'/>
<id>urn:sha1:1f305f99d2001e96daa7e93da4da2bf56da9278e</id>
<content type='text'>
Commit bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
broke the SPI boot on the LS1021ATSN board (ls1021atsn_qspi_defconfig)
at least.

The commit message reads
   Update SCFG_QSPI_CLKSEL value : 0xC -&gt; 0x5
   which means ClusterPLL/16

The original submitted patch had the following description:
   Value 0xC is reserved. Replace it with correct value 0x5 which
   is ClusterPLL/16

Unfortunatly, the little information which was there, was stripped even
further. Why is 0x5 the "correct" value? In fact, it seems that the
upper bit is just ignored and thus the value 0xC translates to 0x4 which
is ClusterPLL/20. This, will result in a SPI clock of 60MHz (if the PLL
is clocked at 1.2GHz). But even that is too much for the (default) 03h
read opcode (max 50MHz). Set the value to ClusterPLL/24 which is 50MHz.

Link: https://lore.kernel.org/r/1568804284-25162-1-git-send-email-kuldeep.singh@nxp.com/
Fixes: bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
Signed-off-by: Michael Walle &lt;mwalle@kernel.org&gt;
Reviewed-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>treewide: Remove Timesys from ADI ADSP maintenance</title>
<updated>2026-03-04T20:25:27Z</updated>
<author>
<name>Philip Molloy</name>
<email>philip.molloy@analog.com</email>
</author>
<published>2026-02-26T11:11:50Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=15e2bacc308d1ea2f50c53f8116fd15ba6c4af6e'/>
<id>urn:sha1:15e2bacc308d1ea2f50c53f8116fd15ba6c4af6e</id>
<content type='text'>
After years of developing the ADI ADSP platform, Timesys was purchased
by another company and is no longer contracted to maintain the platform.

Signed-off-by: Philip Molloy &lt;philip.molloy@analog.com&gt;
Reviewed-by: Greg Malysa &lt;malysagreg@gmail.com&gt;
</content>
</entry>
<entry>
<title>sunxi: clock: H6: add NAND controller clock registers</title>
<updated>2026-02-03T20:45:11Z</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@bootlin.com</email>
</author>
<published>2026-01-23T11:44:55Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=25cbc335b47c30f2cc5c08e9610b47bccead3c2a'/>
<id>urn:sha1:25cbc335b47c30f2cc5c08e9610b47bccead3c2a</id>
<content type='text'>
Add missing NAND controller-related clock registers

The NAND controller on H6/H616 uses one clock for its internal logic
(NAND0_CLK) and one clock for ECC engine (NAND1_CLK) in addition to AHB
and MBUS clocks.

As NAND{0,1}_CLKs and MBUS_GATE are missing, add them.

The bit locations are from H616/H6 User Manual.

Signed-off-by: Richard Genoud &lt;richard.genoud@bootlin.com&gt;
Signed-off-by: Michael Trimarchi &lt;michael@amarulasolutions.com&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: sunxi: remove usage of struct sunxi_ccm_reg</title>
<updated>2026-02-03T20:44:33Z</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@bootlin.com</email>
</author>
<published>2026-01-23T11:44:40Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8034c41d63c985de3bab9980ce81aa70342f64bf'/>
<id>urn:sha1:8034c41d63c985de3bab9980ce81aa70342f64bf</id>
<content type='text'>
The sunxi_ccm_reg is legacy, drop its usage from nand related code

For that, CCU_NAND0_CLK_CFG and CCU_AHB_GATE1 are added to the clock
files when missing.
And clock code in sunxi_nand{,_spl}.c and board.c are changed to use the
new scheme.

Moreover, drop AHB_DIV_1 in favor of the more readable CCM_NAND_CTRL_M/N

Suggested-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Richard Genoud &lt;richard.genoud@bootlin.com&gt;
Signed-off-by: Michael Trimarchi &lt;michael@amarulasolutions.com&gt;
</content>
</entry>
<entry>
<title>sunxi: dram: detect non-power-of-2 sized DRAM chips</title>
<updated>2026-01-25T23:29:32Z</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2025-10-21T23:53:34Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c47b636737366d9bc017b915ca6fcbcce8706e6e'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>misc: ele_api: Add Voltage change start and finish APIs</title>
<updated>2026-01-17T18:00:23Z</updated>
<author>
<name>Ye Li</name>
<email>ye.li@nxp.com</email>
</author>
<published>2026-01-08T11:06:56Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e77d6948f5c2b5fee49b64dbd76bd334219ff963'/>
<id>urn:sha1:e77d6948f5c2b5fee49b64dbd76bd334219ff963</id>
<content type='text'>
On GDET enabled part, need to call voltage change start and finish
APIs when adjust the voltage more than 100mv. Otherwise GDET will be
triggered and system is reset

Reviewed-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Signed-off-by: Ye Li &lt;ye.li@nxp.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>arm: mediatek: remove extra gpio header</title>
<updated>2026-01-16T15:53:57Z</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2026-01-05T20:47:21Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dc82599c45b31b84fcbd0e9c0bf2dcf73f004391'/>
<id>urn:sha1:dc82599c45b31b84fcbd0e9c0bf2dcf73f004391</id>
<content type='text'>
Remove empty gpio.h header file and CONFIG_GPIO_EXTRA_HEADER on
ARCH_MEDIATEK. There is no reason to have these since the header
doesn't contain anything.

Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Reviewed-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'u-boot-amlogic-next-20251219' of https://source.denx.de/u-boot/custodians/u-boot-amlogic into next</title>
<updated>2025-12-19T16:30:26Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-12-19T16:30:26Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=adbbf5982d26801224b10cd847dc468f8b5e4095'/>
<id>urn:sha1:adbbf5982d26801224b10cd847dc468f8b5e4095</id>
<content type='text'>
- Add u-boot SPL support for GX SoCs
- meson_gx_mmc: reduce maximum frequency
- Add support for EFI capsule updates on all Amlogic boards
</content>
</entry>
<entry>
<title>rockchip: sdram: Add rockchip_sdram_type() helper</title>
<updated>2025-12-13T16:02:10Z</updated>
<author>
<name>Jonas Karlman</name>
<email>jonas@kwiboo.se</email>
</author>
<published>2025-08-01T17:09:27Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=57dc75fb9be8f2508cb8c32dc5909c5b57876ace'/>
<id>urn:sha1:57dc75fb9be8f2508cb8c32dc5909c5b57876ace</id>
<content type='text'>
Add a helper function based on rockchip_sdram_size() that return what
DRAM type is used on current running board.

Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</content>
</entry>
<entry>
<title>arm: meson: add support for EFI capsule updates</title>
<updated>2025-12-11T16:27:15Z</updated>
<author>
<name>Ferass El Hafidi</name>
<email>funderscore@postmarketos.org</email>
</author>
<published>2025-12-11T15:37:00Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1bb973b4db6c07b7765b92e93e596907e8b8b469'/>
<id>urn:sha1:1bb973b4db6c07b7765b92e93e596907e8b8b469</id>
<content type='text'>
Previously, few Amlogic devices supported EFI capsule updates.
Generally only the Libre Computer ones with SPI flash supported it,
thanks to board-specific code.

This commit commonises capsule update support across supported
Amlogic boards.  Similar to Qualcomm's support for it, the dfu string
and firmware name is automatically generated at runtime depending on
which device we are booted from.  Right now this supports flashing to
the eMMC/SD and SPI flash.

As usual, the capsule UUID is automatically generated.  You can get it
by enabling CONFIG_CMD_EFIDEBUG and running:

	=&gt; efidebug capsule esrt
	========================================
	ESRT: fw_resource_count=1
	ESRT: fw_resource_count_max=1
	ESRT: fw_resource_version=1
	[entry 0]==============================
	ESRT: fw_class=796180D4-AAB2-50F1-B16A-53DFF9CA89B2
	ESRT: fw_type=unknown
	ESRT: fw_version=0
	ESRT: lowest_supported_fw_version=0
	ESRT: capsule_flags=0
	ESRT: last_attempt_version=0
	ESRT: last_attempt_status=success
	========================================

Reviewed-by: Evgeny Bachinin &lt;EABachinin@salutedevices.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Ferass El Hafidi &lt;funderscore@postmarketos.org&gt;
Link: https://patch.msgid.link/20251211-meson-capsule-v4-1-59f126ba4115@postmarketos.org
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
</content>
</entry>
</feed>
