cpp/unstable,now 4:13.1.0-4 riscv64 [installed,automatic]
cpp-12/unstable,now 12.3.0-6 riscv64 [installed,automatic]
cpp-13/unstable,now 13.1.0-9 riscv64 [installed,automatic]
dpkg-dev/unstable,now 1.21.22 all [installed,automatic]
gcc/unstable,now 4:13.1.0-4 riscv64 [installed,automatic]
gcc-12/unstable,now 12.3.0-6 riscv64 [installed,automatic]
gcc-12-base/unstable,now 12.3.0-6 riscv64 [installed]
gcc-12-plugin-dev/unstable,now 12.3.0-6 riscv64 [installed]
gcc-13/unstable,now 13.1.0-9 riscv64 [installed,automatic]
gcc-13-base/unstable,now 13.1.0-9 riscv64 [installed,automatic]
libatomic1/unstable,now 13.1.0-9 riscv64 [installed]
libcc1-0/unstable,now 13.1.0-9 riscv64 [installed,automatic]
libgcc-12-dev/unstable,now 12.3.0-6 riscv64 [installed,automatic]
libgcc-13-dev/unstable,now 13.1.0-9 riscv64 [installed,automatic]
libgcc-s1/unstable,now 13.1.0-9 riscv64 [installed]
libgomp1/unstable,now 13.1.0-9 riscv64 [installed,automatic]
root@risc-v:/Transit/linux#
So your default gcc is 13, install gcc-13-plugin-dev instead
@chbinnc Thanks for the tip. Now my GCC-plugin options are anabled.
However, when I select -
I am greeted with these options -
I have no possibility to enter “y” or “m”.
Have I missed something here?
Aubrey
Just press Enter on the first one and choose
zero-init everything passed by reference (very strong)
@chninnc - That worked (a bit misleading). Thanks. Will report back.
@chbinnc The kernel compile works.
Thank you for your time and the assistance rendered.
A last question, why do I/we need all of this kernel hardening GCC Plugins (more overhead…) etc?
Regards
Aubrey
I don’t know, guess it is related to Gnome or GPU.
@chbinnc
FYI - The kernel compiles and boots cleanly without the GCC Plugins being enabled also.
Aubrey
For a partial build (just remove the gcc-plugins options in the kernel and make again) or a complete build (pull the kernel sourcecode again and make)?
Partial build.
Something strange now…
Yesterday, I had 8GB RAM, after this kernel build, I now have only 4GB.
Firmware (U-Boot and SPL) is up to date.
Any ideas?
Aubrey
Could the wrong/old/incorrect DTB’s have been pulled in?
Aubrey
I only have a 4GB v1.2a board. Do a search on the forum and find this topic:
So manually change arch/riscv/boot/dts/starfive/jh7110-visionfive-v2.dtsi#L47
memory@40000000 {
device_type = "memory";
reg = <0x0 0x40000000 0x1 0x0>;
};
to
memory@40000000 {
device_type = "memory";
reg = <0x0 0x40000000 0x2 0x0>;
};
may help.
@chbinnc Just done so and rebooted. Now 8GB. Where did this “wrong” jh7110-visionfive-v2.dtb come from??
Aubrey
Did you make dtbs_install?
I did indeed, as per your instructions. The “wrong” DTB - jh7110-visionfive-v2.dts ended up in /boot/dtbs/new/starfive.
I had to extract, edit and replace the above with the correct value.
Aubrey
I’ve got the same problem, recompiled kernel recognize 4GB of memory. I don’t understand how it works, there is only one version of jh7110-visionfive-v2.dtsi in git repo and it has 4GB setting. But if you decompile the dtb file that got installed with “standard” kernel that setting is for 8GB. Where is the magic that change it?
maybe some thing in this file?
I (again) had exactly the same problem with the last binary distribution. On decompiling the dtb file, it has the 4GB setting.
Editing to the 8GB setting and recompiling /boot/dbts/starfive/jh7110-visionfive-v2.dtb fixed it.
I can’t see how anything in this file can change memory setting. But there is something in u-boot/include/configs/starfive-visionfive2.h:visionfive2_mem_set which appears to modify that value in fdt ->in memory<- before booting linux. At least that is my guess. However if that what it is, it does not work correctly. Or maybe this is not what that code is for.
Edit: I found the following comment in git commit related to the above code "Visionfive2 has a 2/4/8G version. You need to read eeprom information in uboot to obtain the size of mem, and modify the size of mem in linux dts. So this seems to be the right code, however it’s broken.
Edit: I may have figured something. The name of directories (dtbs/starfive) as well as the name of jh7110-visionfive-v2.dtb file are hard-coded in a code responsible for adjusting memory parameter. If you use exact same path and names, during the boot and before loading Linux this dtb file will get adjusted with correct value. If you change the path or the name it will not get adjusted and you’ll have 4GB.
I wanted to state at bootup, IT IS DEFINITELY NOT dtbs/starfive/*.dtb that get loaded.
It is /boot/starfive/jh7110-visionfive-v2.dtb