Bug 1214902 - devel:RISCV:Factory:Contrib:StarFive:VisionFive2 uses 8GiB of memory on a board that only has 4GiB
Summary: devel:RISCV:Factory:Contrib:StarFive:VisionFive2 uses 8GiB of memory on a boa...
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader (show other bugs)
Version: Current
Hardware: RISC-V openSUSE Tumbleweed
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Andreas Schwab
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-02 16:57 UTC by Michael Laß
Modified: 2023-12-05 10:12 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Laß 2023-09-02 16:57:45 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.
Comment 1 Michael Laß 2023-09-16 11:00:05 UTC
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.
Comment 2 Andreas Schwab 2023-10-10 09:49:19 UTC
Please try again.
Comment 3 Andreas Schwab 2023-10-10 12:14:21 UTC
The problem is that read_eeprom fails in SPL.
Comment 4 Andreas Schwab 2023-12-05 10:12:03 UTC
Fixed.