Device trees limit Linux to 4GB of RAM on 8GB devices

[strlcat]

Hi, please accept my thanks for development and release of this wonderful board.
There is small issue with device trees which can confuse newcomers like me:

in current linux you provide there, in https://github.com/starfive-tech/linux/blob/f0fce0037f9cc3fa6013d14d2f11fff7cf1a19da/arch/riscv/boot/dts/starfive/jh7110-visionfive-v2.dtsi#L47

	memory@40000000 {
		device_type = "memory";
		reg = <0x0 0x40000000 0x1 0x0>;
	};

states that only 4GB will be visible to Linux.

Situation: I ordered 8GB version, downloaded Debian Image-69 and booted, but I've seen only around 4GB of free RAM and I immediately thought that I received wrong package. But thanks to people from #riscv-main @ matrix.org I nailed down that my device is okay but wrong DTS statement limits Linux to 4GB instead of 8GB RAM.

As a quick hack I had to change it to:

	memory@40000000 {
		device_type = "memory";
		reg = <0x0 0x40000000 0x2 0x0>;
	};

(note 0x1 was changed to 0x2 in reg statement),
and Debian seen full amount of RAM.

If this issue is wrong (I booted Debian with default U-Boot environment with U-Boot updated from this repo after I received my board), then please ignore.

Thank you!

[dtometzki]

Hello @electrorys

you are correct the default U-boot env. has an issue with the correct RAM size.

[antoinecarme]

@electrorys @dtometzki

Is there a quick fix for this until the next debian image release ?

[dtometzki]

Hello,

with an update of u-boot and opensbi and the new Debian Image 69 the issue is solved.

[antoinecarme]

@dtometzki

Thanks for your answer.

With u-boot and opensbi updated (flashcp x 2) and the minimal Debian Image 69, I only see 4GB.

Is there a u-boot parameter I can set manually ?

[dtometzki]

Hello,

do you used the both files from here to flash https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v2.5.0 ?

[antoinecarme]

Yes.

[strlcat]

Hi,
If anyone still experience this type of bug even with updated softwares, this is what I was adviced to do when fixed mine:

1. Decompile your source dtb:
   cd /tmp; dtc -I dtb -O dts /sys/firmware/fdt -o vf2.dts # on system booted up, or place path to your dtb in place of /sys/firmware/fdt. Ignore any warnings it produces. If dtc tool is not installed, try installing it: apt install device-tree-compiler or how dtc is named in your distro. Alternatively, dtc from Linux kernel tree also can be used (you have to run make menuconfig first to produce executable).
2. Edit vf2.dts: Find section which starts with memory@4. Your line of interest is reg = <0x00 0x40000000 0x01 0x00>; or reg = <0x00 0x40000000 0x1 0x00>;. You shall replace it with reg = <0x00 0x40000000 0x02 0x00>;. Notice 0x02 and not 0x01.
3. Compile file back: dtc -I dts -O dtb -o /boot/dtbs/starfive/vf2.dtb vf2.dts. Again, if no errors and only warnings, you're good to go.
4. Boot with modified vf2.dtb: in U-Boot prompt you might want to setenv fdtfile starfive/vf2.dtb followed by saveenv. YMMV.

It worked fine for me this way.

[antoinecarme]

@electrorys

Excellent. It works!!! Decompiling and recompiling the dtb file was enough. I now see 8GB instead of 4GB.

Thank you so much.

[jrtc27]

The problem is visionfive2_mem_set is only run for bootcmd_distro (which AFAICT nothing actually runs, since boot_targets its "mmc0 dhcp") via set_fdt_distro. Neither bootcmd_mmc0 nor bootcmd_dhcp call it.

The whole set of U-Boot scripts seems like a mess. Hopefully upstreaming cleans this up to be sane (and adds both USB and PCIe support...).

[MichaIng]

You need a 3rd FAT boot partition with uEnv.txt to change the

boot_targets=distro mmc0 dhcp

to have bootcmd_distro called for this to work. It's a problem that

1. visionfive2_mem_set isn't called regardless of which boot target is used
2. the uEnv.txt is loaded only from a 3rd FAT partition, which doesn't allow a normal partitioning (single Linux partition)

fw_printenv and fw_setenv can be used to check and change the U-Boot environment on SPI flash, but the /dev/mtd* device and location of the environment needs to be known and set up in /etc/fw_env.config.

[sndwvs]

Hi, If anyone still experience this type of bug even with updated softwares, this is what I was adviced to do when fixed mine:

1. Decompile your source dtb:
   `cd /tmp; dtc -I dtb -O dts /sys/firmware/fdt -o vf2.dts` # on system booted up, or place path to your dtb in place of `/sys/firmware/fdt`. Ignore any warnings it produces. If `dtc` tool is not installed, try installing it: `apt install device-tree-compiler` or how dtc is named in your distro. Alternatively, `dtc` from Linux kernel tree also can be used (you have to run `make menuconfig` first to produce executable).

2. Edit vf2.dts: Find section which starts with `memory@4`. Your line of interest is `reg = <0x00 0x40000000 0x01 0x00>;` or `reg = <0x00 0x40000000 0x1 0x00>;`. You shall replace it with `reg = <0x00 0x40000000 0x02 0x00>;`. Notice `0x02` and not `0x01`.

3. Compile file back: `dtc -I dts -O dtb -o /boot/dtbs/starfive/vf2.dtb vf2.dts`. Again, if no errors and only warnings, you're good to go.

4. Boot with modified `vf2.dtb`: in U-Boot prompt you might want to `setenv fdtfile starfive/vf2.dtb` followed by `saveenv`. YMMV.

It worked fine for me this way.

Having tried different images for a board with 8GB of memory, with a native bootloader, 4GB is always available, so I made an overlay file to configure the 8GB memory

[omac777]

At bootup, the default dtb was not /boot/dtbs/starfive/jh7110-visionfive-v2.dtb that got loaded.

I would recommend using this:
dtc -I dts -O dtb -o /boot/starfive/jh7110-visionfive-v2.dtb vf2.dts

In that manner, you don't have to modify or use setenv to point to something new. Thank you for listening.