Debian 12 build recognized only 4Gb of RAM from 8Gb installed on device

dengolius · August 14, 2024, 9:58am

Hello all!
I’ve tried to use a ready-to-use image for my StarFive 2 with 8Gb of RAM but it can’t recognize that my board has 8Gb, it only sees half of it.
I used this image from Microsoft OneDrive
This build also doesn’t have dm_thin_pool module and a docker engine as the official documentation says. I’ve installed docker from the apt - but the docker service failed to start because of an issue with missed dm_thin_pool.

Then I write the Ubuntu 24.04 from ubuntu com/download/risc-v and try to test it. I can confirm that Ubuntu 24.04 sees all 8Gb of RAM and works well. I didn’t try to install docker but I can confirm that Ubuntu works with Ubuntu repositories and can upgrade from it.

Here is some screenshots:

https://imgur.com/a/e61krFo

martin.wozenilek · August 14, 2024, 10:25am

Good chance that this is related to the device tree. If you search this forum or the web you will find the needed steps to change the dtd files:

github.com/starfive-tech/VisionFive2

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

opened 05:49PM - 04 Jan 23 UTC

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!

dengolius · August 14, 2024, 12:04pm

Sorry, as I see this is a known issue but the fresh builds don’t contain a fix.
I know that debian builds are in development but still can’t understand why it is not fixed yet for 1.5 year 0_o ?

mzs · August 15, 2024, 12:51am

did you update your qspi flash VisionFive 2 Debian 202405 Released

dengolius · August 15, 2024, 6:33am

Nope. As I said before I opened the wiki and used a link to onedrive for the image.

Folks, I understand that it is a development board and a Debian development build, but I don’t understand why this small bug is present and needs to be fixed on the user side. As an example I shared that Ubuntu just works, so I suppose to think that the official build which is mentioned in the documentation or release notes will have a guide on how to fix this issue. Instead, I need to spend a few days just to google it and forum to find that it is a known issue.

Is it difficult to update documentation in time and make it more attractive and understandable for users?

ganboing · August 16, 2024, 3:18am

This is indeed an annoying problem. The issue is not with the dtb file itself, but rather somewhere in the boot process. The same dtb is used in all flavors of the board with different memory sizes. It’s the job of u-boot to fixup the dtb before handling off to Linux.

starfive version:

github.com

starfive-tech/u-boot/blob/JH7110_VisionFive2_devel/include/configs/starfive-visionfive2.h#L206


      
          	"fdt set /soc/ethernet@16040000 phy-mode \"rmii\";"					\
          	"fdt set /soc/ethernet@16040000 assigned-clocks <0x00000003 0x00000069 0x00000003 0x00000067>;"	\
          	"fdt set /soc/ethernet@16040000 assigned-clock-parents <0x00000003 0x00000065 0x00000003 0x00000065>;"	\
          	"fdt rm /soc/ethernet@16040000/mdio/ethernet-phy@1 motorcomm,tx-clk-adj-enabled;"	\
          	"fdt rm /soc/ethernet@16040000/mdio/ethernet-phy@1 motorcomm,tx-clk-100-inverted;"	\
          	"fdt rm /soc/ethernet@16040000/mdio/ethernet-phy@1 motorcomm,rx-clk-drv-microamp;"	\
          	"fdt rm /soc/ethernet@16040000/mdio/ethernet-phy@1 motorcomm,rx-data-drv-microamp;"	\
          	"fdt rm /soc/ethernet@16040000/mdio/ethernet-phy@1 rx-internal-delay-ps;"		\
          	"fdt rm /soc/ethernet@16040000/mdio/ethernet-phy@1 tx-internal-delay-ps; \0"
          
          #define VISIONFIVE2_MEM_SET	\
          	"visionfive2_mem_set="	\
          	"fdt memory ${memory_addr} ${memory_size};" \
          	"run cma_resize; \0"
          
          #define CHIPA_SET	\
          	"chipa_set="				\
          	"if test ${chip_vision} = A; then "					\
          		"fdt get name gmac1_subnode_name /soc/ethernet@16040000 0;"	\
          		"if test ${gmac1_subnode_name} = mdio; then "			\
          			"setenv gmac_conf_new 1;"				\

upstream version:

github.com

u-boot/u-boot/blob/master/board/starfive/visionfive2/starfive_visionfive2.c#L131


      
          	if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
          		if (gd->arch.firmware_fdt_addr)
          			return (ulong *)(uintptr_t)gd->arch.firmware_fdt_addr;
          	}
          
          	return (ulong *)_end;
          }
          
          int ft_board_setup(void *blob, struct bd_info *bd)
          {
          	return fdt_fixup_memory(blob, 0x40000000, gd->ram_size);
          }

Thus, all boot stages are tightly coupled (among other things). If you are using starfive2 image, then use their bootloader. If ubuntu, then ubuntu image+bootloader. Don’t mix-and-match u-boot/opensbi/kernel+dtb binaries from upstream/starfive/ubuntu. starfive’s image is debian based, but it seems that there’s no upstream official image (Ref: InstallingDebianOn/StarFive/VisionFiveV2 - Debian Wiki)

My take on jh7110/vf2: the support is slowly getting there, but still there are drivers not yet upstreamed, and there’re potentially hw bugs involving PCIe: (Ref: Re: [PATCH v15,RESEND 22/23] PCI: starfive: Offload the NVMe timeout workaround to host drivers. - Kevin Xie) The starfive debian image is absolutely not production ready, as it’s known to break after an apt upgrade Ubuntu official image is probably more promising, but the lack of upstream GPU driver is still a big problem. To me this board is really for someone who’s deeply rooting for risc-v. If not, the ARM side of things are better candidates for you. Things might get better after framework’s new jh7110-based board: Framework | Introducing a new RISC-V Mainboard from DeepComputing I hope by that time Ubuntu/Fedora will have a reasonably usable image with GPU drivers, etc.