On 02.08.18 23:31, Dr. Philipp Tomsich wrote: > >> On 2 Aug 2018, at 22:36, Simon Glass <s...@chromium.org> wrote: >> >> On 26 July 2018 at 07:59, Philipp Tomsich >> <philipp.toms...@theobroma-systems.com >> <mailto:philipp.toms...@theobroma-systems.com>> wrote: >>> Even on 32bit systems a full 4GB of DRAM may be installed and reported >>> by the DRAM controller. Whether these 4GB are larger available >>> depends on the size/configuration of address decoding windows and >>> architectural features (e.g. consider a hypothetical architecture that >>> uses dedicated instructions to access the 'memory-mapped' peripheral >>> IO ranges). In U-Boot, the available DRAM, as reported by the >>> device-model is independent of the accessible DRAM (i.e. adjusted top >>> and effective size). >>> >>> This was first reported against the RK3288, which may have 4GB DRAM >>> attached, but will have a small (e.g. 128MB) window not accessible due >>> to address decoding limitations. >>> >>> The solution is to increase the types used for storing the ram_size to >>> have at least 33 bits even on 32bit systems... i.e. we need to use a >>> u64 for these always (this was previously only the case for >>> PHYS_64BIT, which will have unwanted side-effects for 32bit systems >>> and would require more intrusive changes). >>> >>> This commit changes the size-field in 'struct ram' and the ram_size in >>> 'gd' to be a u64. >>> >>> Reported-by: Marty E. Plummer <hanet...@startmail.com> >>> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> >>> --- >>> >>> include/asm-generic/global_data.h | 2 +- >>> include/ram.h | 9 ++++++++- >>> 2 files changed, 9 insertions(+), 2 deletions(-) >>> >> >> Reviewed-by: Simon Glass <s...@chromium.org <mailto:s...@chromium.org>> >> >>> diff --git a/include/asm-generic/global_data.h >>> b/include/asm-generic/global_data.h >>> index 0fd4900..f3d687c 100644 >>> --- a/include/asm-generic/global_data.h >>> +++ b/include/asm-generic/global_data.h >>> @@ -55,7 +55,7 @@ typedef struct global_data { >>> unsigned long ram_base; /* Base address of RAM used by >>> U-Boot */ >>> unsigned long ram_top; /* Top address of RAM used by U-Boot >>> */ >>> unsigned long relocaddr; /* Start address of U-Boot in RAM */ >>> - phys_size_t ram_size; /* RAM size */ >>> + u64 ram_size; /* RAM size */ >>> unsigned long mon_len; /* monitor len */ >>> unsigned long irq_sp; /* irq stack pointer */ >>> unsigned long start_addr_sp; /* start_addr_stackpointer */ >>> diff --git a/include/ram.h b/include/ram.h >>> index 67e22d7..1fe024f 100644 >>> --- a/include/ram.h >>> +++ b/include/ram.h >>> @@ -9,7 +9,14 @@ >>> >>> struct ram_info { >>> phys_addr_t base; >>> - size_t size; >>> + /* >>> + * We use a 64bit type for the size to correctly handle 32bit >>> + * systems with 4GB of DRAM (which would overflow a 32bit type >>> + * and read back as 0). For 64bit systems, we assume (for now) >> >> forever :-) >> >>> + * that they will always have less than 2^65 byte of DRAM >>> + * installed. -- prt >> >> Is the prt your signature? I suggest dropping it. > > In fact it is. But I’ll need to rewrite the entire comment anyway for the next > version of this series as there’s even more functions and places that the > memory size is stored in... > >> >>> + */ >>> + u64 size;
With LPAE available in all modern ARM cores, shouldn't phys_addr_t just be u64? And then we'd probably want to use that throughout the code, right? Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
