<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/riscv/cpu, branch next</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/arch/riscv/cpu?h=next</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/arch/riscv/cpu?h=next'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2026-06-25T00:13:24Z</updated>
<entry>
<title>treewide: move bi_dram[] from bd to gd</title>
<updated>2026-06-25T00:13:24Z</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2026-06-17T07:48:19Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1174c99ab421168221be372bd83a4143bf5f167d'/>
<id>urn:sha1:1174c99ab421168221be372bd83a4143bf5f167d</id>
<content type='text'>
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.

By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.

Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.

Reviewed-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Tested-by: Michal Simek &lt;michal.simek@amd.com&gt; # Versal Gen 2 Vek385
Tested-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Tested-by: Christophe Leroy (CS GROUP) &lt;chleroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>eeprom: starfive: Simplify get_ddr_size_from_eeprom()</title>
<updated>2026-03-16T17:36:57Z</updated>
<author>
<name>Hal Feng</name>
<email>hal.feng@starfivetech.com</email>
</author>
<published>2025-10-24T08:59:26Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6015c98be50f2fc571c294d2f2b0768212fb7e99'/>
<id>urn:sha1:6015c98be50f2fc571c294d2f2b0768212fb7e99</id>
<content type='text'>
Directly return the DDR size instead of the field of 'DxxxExxx'.
Move the function description to the header file.
Return 0 instead of 0xFF if read_eeprom() fails.

Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Fixes: aea1bd95b61e ("eeprom: starfive: Enable ID EEPROM configuration")
Signed-off-by: Hal Feng &lt;hal.feng@starfivetech.com&gt;
</content>
</entry>
<entry>
<title>riscv: mpfs: SIFIVE_CLINT and SPL_SIFIVE_CLINT don't exist</title>
<updated>2026-03-12T18:57:58Z</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2026-02-25T17:52:29Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=12a9c83cba29b0acf3d41fb40de6416c473c0ba3'/>
<id>urn:sha1:12a9c83cba29b0acf3d41fb40de6416c473c0ba3</id>
<content type='text'>
Don't imply non-existent symbols CONFIG_SIFIVE_CLINT and SPL_SIFIVE_CLINT.

MPFS boards neither use SPL nor do they run main U-Boot in M-mode.
So we don't need CONFIG_(SPL_)ACLINT either.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Acked-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</content>
</entry>
<entry>
<title>sifive: switch to OF_UPSTREAM</title>
<updated>2026-03-12T18:56:52Z</updated>
<author>
<name>Andreas Schwab</name>
<email>schwab@suse.de</email>
</author>
<published>2026-01-28T16:51:02Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4dcff3b572a1d67c35b7ed71253a6d85aefe4e9b'/>
<id>urn:sha1:4dcff3b572a1d67c35b7ed71253a6d85aefe4e9b</id>
<content type='text'>
Tested on HiFive Unleashed and HiFive Unmatched, both SPIFlash and MMC boot.

Signed-off-by: Andreas Schwab &lt;schwab@suse.de&gt;
Reviewed-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
</content>
</entry>
<entry>
<title>treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage</title>
<updated>2026-02-17T19:50:22Z</updated>
<author>
<name>Peng Fan</name>
<email>peng.fan@nxp.com</email>
</author>
<published>2026-02-09T01:30:18Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0f90b1e715f8abe41b0875752eb184f46032ff11'/>
<id>urn:sha1:0f90b1e715f8abe41b0875752eb184f46032ff11</id>
<content type='text'>
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt; #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal &lt;anshuld@ti.com&gt; #TI boards
Acked-by: Yao Zi &lt;me@ziyao.cc&gt; #TH1520
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>riscv: Update linker scripts to ensure appended device tree is aligned</title>
<updated>2026-01-20T18:07:21Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-15T22:19:38Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f150843499b3139c2358f5659411571399902d4a'/>
<id>urn:sha1:f150843499b3139c2358f5659411571399902d4a</id>
<content type='text'>
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end (for U-Boot) or _image_binary_end
  (for xPL phases) by 8-bytes by adding '. = ALIGN(8);' to the final
  section before the symbol.
- Remove a now-spurious  '. = ALIGN(x);' statement that was intended to
  provide the above alignments.
- Ensure that we do have alignment by adding an ASSERT so that when not
  aligned we fail to link (and explain why).

Reviewed-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>riscv: mpfs: move SoC level options to the CPU Kconfig</title>
<updated>2025-12-08T04:10:43Z</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2025-11-19T12:38:43Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2f7420ccaacb7d886b6931c6a82d7ef80c25885d'/>
<id>urn:sha1:2f7420ccaacb7d886b6931c6a82d7ef80c25885d</id>
<content type='text'>
There are multiple boards that use the PolarFire SoC, so extract
the Kconfig sections that are determined at a CPU level from the board
Kconfigs now that we have a CPU Kconfig.

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</content>
</entry>
<entry>
<title>riscv: create a custom CPU implementation for PolarFire SoC</title>
<updated>2025-12-08T04:10:39Z</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2025-11-19T12:38:42Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4d056a2037d3b4604ce2592d40ae24c6d7cf03bf'/>
<id>urn:sha1:4d056a2037d3b4604ce2592d40ae24c6d7cf03bf</id>
<content type='text'>
PolarFire SoC needs a custom implementation of top_of_ram(), so stop
using the generic CPU &amp; create a custom CPU instead.

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Reviewed-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
</content>
</entry>
<entry>
<title>riscv: cpu: Beautify the warning message</title>
<updated>2025-12-08T04:10:10Z</updated>
<author>
<name>Leo Yu-Chi Liang</name>
<email>ycliang@andestech.com</email>
</author>
<published>2025-10-29T07:58:39Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3b8a3df19126858e2a4c71661bd37f55bf0ad3b3'/>
<id>urn:sha1:3b8a3df19126858e2a4c71661bd37f55bf0ad3b3</id>
<content type='text'>
Add '\n' to the end of the warning message.

Besides, if we enable console record utility,
missing the '\n' causes the console_record_readline
fail to recognize the end of string.

Signed-off-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
</content>
</entry>
<entry>
<title>Revert "riscv: Add a Zalrsc-only alternative for synchronization in start.S"</title>
<updated>2025-10-16T08:36:37Z</updated>
<author>
<name>Yao Zi</name>
<email>ziyao@disroot.org</email>
</author>
<published>2025-09-25T16:01:48Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e6646b35f410c4ffbdb0f309d4dad1e16c1e4714'/>
<id>urn:sha1:e6646b35f410c4ffbdb0f309d4dad1e16c1e4714</id>
<content type='text'>
This reverts commit a681cfecb4346107212f377e2075f6eb1bdc6a2b.

It has been reported that the commit causes boot regression for SPL on
StarFive VisionFive 2 or compatible boards. Inspecting the code, I did
spot one logic error for deciding whether Zaamo or Zalrsc is used, and
it's still unclear what exactly causes the regression, let's revert it
for now.

Reported-by: E Shattow &lt;e@freeshell.de&gt;
Link: https://lore.kernel.org/u-boot/1871663e-b918-4351-9e9e-97f9a4c73733@freeshell.de/
Signed-off-by: Yao Zi &lt;ziyao@disroot.org&gt;
Acked-by: E Shattow &lt;e@freeshell.de&gt;
Acked-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
</content>
</entry>
</feed>
