Bugzilla – Bug 1214902
devel:RISCV:Factory:Contrib:StarFive:VisionFive2 uses 8GiB of memory on a board that only has 4GiB
Last modified: 2023-12-05 10:12:03 UTC
I flashed the openSUSE-Tumbleweed-RISC-V-JeOS-starfivevisionfive2.riscv64.raw.xz built on 2023-09-02-03:55 onto a VisionFive2 board with 4GiB of memory. After booting it, Linux shows 8GiB of total memory. Doing somewhat memory-intensive operations then leads to segfaults. I found out that this problem is already present in u-boot. On startup it shows --- start of u-boot snippet --- U-Boot SPL 2023.10-rc3 (Jul 11 2023 - 00:00:00 +0000) DDR version: dc2e84f0. Trying to boot from MMC2 U-Boot 2023.10-rc3 (Jul 11 2023 - 00:00:00 +0000) CPU: rv64imafdc_zba_zbb Model: StarFive VisionFive 2 v1.3B DRAM: 8 GiB Core: 124 devices, 23 uclasses, devicetree: board MMC: mmc@16010000: 0, mmc@16020000: 1 Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment [...] --- end of u-boot snippet --- It turns out that the DTB included in u-boot by default configures 8GiB and then at runtime, depending on data in the EEPROM, this value is supposed to be changed to the actual available memory: https://source.denx.de/u-boot/u-boot/-/commit/38d900b409199df02a1a26dfcb464d4d2b6e27d2 However, with the openSUSE build of u-boot, this does not happen: --- start of u-boot snippet --- StarFive # fdt print /memory@40000000 reg reg = <0x00000000 0x40000000 0x00000002 0x00000000> --- end of u-boot snippet --- Here, the 2 in the third word marks 8GiB as memory size. This also reflects under /proc/device-tree in Linux: --- start of Linux snippet --- starfive:~ # hexdump /proc/device-tree/memory\@40000000/reg 0000000 0000 0000 0040 0000 0000 0200 0000 0000 0000010 --- end of Linux snippet --- I attempted to modify the device-tree on-the-fly in u-boot before booting: --- start of u-boot snippet --- StarFive # fdt set /memory@40000000 reg <0x00000000 0x40000000 0x00000001 0x00000000> StarFive # fdt print /memory@40000000 reg reg = <0x00000000 0x40000000 0x00000001 0x00000000> StarFive # boot --- end of u-boot snippet --- but this did not help. Linux still assumes that there are 8GiB of memory, although the change reflects under /proc/device-tree: --- start of Linux snippet --- starfive:~ # hexdump /proc/device-tree/memory\@40000000/reg 0000000 0000 0000 0040 0000 0000 0100 0000 0000 0000010 --- end of Linux snippet --- I also tried adding devicetree /boot/dtb/starfive/jh7110-starfive-visionfive-2-v1.3b.dtb to the grub boot entry as this dtb file reflects the 4GiB model but this had no effect at all. At this point, I am not sure if this is an upstream issue in that the auto detection of available memory in u-boot does not yet work correctly, or an issue specific to openSUSE. The fact that the manual change via "fdt set" did not help could mean that there are multiple issues here. I'll gladly help with further information if required.
It's still an issue with today's image that comes with u-boot 2023.10-rc4. The issue can be worked around though by adding `mem=4G` as kernel argument to the grub config. /proc/iomem will then show 13fffffff as last address for System RAM, which looks correct.
Please try again.
The problem is that read_eeprom fails in SPL.
Fixed.