u-boot.git/arch/riscv/cpu/generic/dram.c, branch master Unnamed repository; edit this file 'description' to name the repository. treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage 2026-02-17T19:50:22+00:00 Peng Fan peng.fan@nxp.com 2026-02-09T01:30:18+00:00 0f90b1e715f8abe41b0875752eb184f46032ff11 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 <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards Acked-by: Yao Zi <me@ziyao.cc> #TH1520 Signed-off-by: Peng Fan <peng.fan@nxp.com> 
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 <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
riscv: Remove common.h usage 2023-10-24T20:34:45+00:00 Tom Rini trini@konsulko.com 2023-10-12T23:03:59+00:00 0b9441ae76db88b6871adc31b7e59355286f2847 We can remove common.h from most cases of the code here, and only a few places need an additional header instead. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Rick Chen <rick@andestech.com> 
We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>
riscv: remove dram_init_banksize() 2023-10-19T09:29:32+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2023-09-26T07:16:34+00:00 9385c9b0cd9761b49033df13ccf45d3dd17f4027 Remove dram_init_banksize() on the architecture level. Limiting used RAM to under 4 GiB is only necessary for CPUs which have a DMA issue. SoC specific code already exists for FU540, FU740, JH7110. Not all RISC-V boards will have memory below 4 GiB. A weak implementation of dram_init_banksize() exists in common/board_f.c. See the discussion in https://lore.kernel.org/u-boot/545fe813-cb1e-469c-a131-0025c77aeaa2@canonical.com/T/ Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Anup Patel <anup@brainfault.org> 
Remove dram_init_banksize() on the architecture level.

Limiting used RAM to under 4 GiB is only necessary for CPUs which have a
DMA issue. SoC specific code already exists for FU540, FU740, JH7110.

Not all RISC-V boards will have memory below 4 GiB.

A weak implementation of dram_init_banksize() exists in common/board_f.c.

See the discussion in
https://lore.kernel.org/u-boot/545fe813-cb1e-469c-a131-0025c77aeaa2@canonical.com/T/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
common: return type board_get_usable_ram_top 2023-08-15T16:21:17+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2023-08-12T18:16:58+00:00 d768dd88552df18d4a0527cf3d6ddd05dc072f02 board_get_usable_ram_top() returns a physical address that is stored in gd->ram_top. The return type of the function should be phys_addr_t like the current type of gd->ram_top. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
board_get_usable_ram_top() returns a physical address that is stored in
gd->ram_top. The return type of the function should be phys_addr_t like the
current type of gd->ram_top.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
board_f: Fix types for board_get_usable_ram_top() 2022-09-23T19:12:42+00:00 Pali Rohár pali@kernel.org 2022-09-09T15:32:40+00:00 049704f808d5e643668a33a76e55f925d4c1b36a Commit 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t") changed type of ram_top member from ulong to phys_addr_t but did not changed types in board_get_usable_ram_top() function which returns value for ram_top. So change ulong to phys_addr_t type also in board_get_usable_ram_top() signature and implementations. Fixes: 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
Commit 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.

So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.

Fixes: 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Merge branch '2021-02-02-drop-asm_global_data-when-unused' 2021-02-15T15:16:45+00:00 Tom Rini trini@konsulko.com 2021-02-15T13:19:40+00:00 2ae80437fbe0181184ae4b188b89629b902702c6 - Merge the patch to take <asm/global_data.h> out of <common.h> 
- Merge the patch to take <asm/global_data.h> out of <common.h>
riscv: Adjust board_get_usable_ram_top() for 32-bit 2021-02-03T10:38:41+00:00 Bin Meng bin.meng@windriver.com 2021-01-31T12:35:57+00:00 85c714d8dcd56f63c2c0ae1b0f6a7e4a96c918a4 When testing QEMU RISC-V 'virt' machine with a 2 GiB memory configuration, it was discovered gd->ram_top is assigned to value zero in setup_dest_addr(). While gd->ram_top should not be declared as type `unsigned long`, which will be updated in a future patch, the current logic in board_get_usable_ram_top() can be updated to cover both 64-bit and 32-bit RISC-V. Signed-off-by: Bin Meng <bin.meng@windriver.com> 
When testing QEMU RISC-V 'virt' machine with a 2 GiB memory
configuration, it was discovered gd->ram_top is assigned to
value zero in setup_dest_addr().

While gd->ram_top should not be declared as type `unsigned long`,
which will be updated in a future patch, the current logic in
board_get_usable_ram_top() can be updated to cover both 64-bit
and 32-bit RISC-V.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
common: Drop asm/global_data.h from common header 2021-02-02T20:33:42+00:00 Simon Glass sjg@chromium.org 2020-10-31T03:38:53+00:00 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> 
Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
common: Move board_get_usable_ram_top() out of common.h 2019-12-02T23:25:04+00:00 Simon Glass sjg@chromium.org 2019-11-14T19:57:45+00:00 67c4e9f815eb75ba5c1f86213eded93c4e06e64b Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> 
Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems 2019-02-27T01:12:33+00:00 Anup Patel Anup.Patel@wdc.com 2019-02-25T08:14:30+00:00 26f4fd1cb4f6808328e8eab2afe7454172fe6d2c On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot DMA mapping APIs will generate DMA addresses beyond 4GB. This breaks DMA programming in 32bit DMA capable devices (such as Cadence MACB ethernet). For example, If DRAM is more then 2GB on QEMU sifive_u machine then Cadence MACB ethernet stops working for U-Boot because it is a 32bit DMA capable device. To handle 32bit DMA capable devices on 64bit systems, we provide custom implementation of board_get_usable_ram_top() which ensures that usable ram top is not more then 4GB. This in-turn ensures that U-Boot always runs within 4GB hence DMA addresses generated by DMA mapping APIs will be within 4GB too. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alexander Graf <agraf@suse.de> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
DMA mapping APIs will generate DMA addresses beyond 4GB. This
breaks DMA programming in 32bit DMA capable devices (such as
Cadence MACB ethernet). For example, If DRAM is more then 2GB
on QEMU sifive_u machine then Cadence MACB ethernet stops working
for U-Boot because it is a 32bit DMA capable device.

To handle 32bit DMA capable devices on 64bit systems, we provide
custom implementation of board_get_usable_ram_top() which ensures
that usable ram top is not more then 4GB. This in-turn ensures
that U-Boot always runs within 4GB hence DMA addresses generated
by DMA mapping APIs will be within 4GB too.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>