NixOS RISC-V - Public Room Timeline

	NixOS RISC-V	205 Members
	NixOS on RISC-V https://wiki.nixos.org/wiki/RISC-V https://pad.lassul.us/NixOS-riscv64-linux https://github.com/orgs/NixOS/teams/risc-v	62 Servers

Load older messages

Sender	Message	Time
12 Nov 2025
Tristan Ross	Dang, so much faster than the VisionFive 2 lol	06:45:04
dramforever	eic7702x should have much better io and memory bw in addition to faster cores	06:48:41
dramforever	and twice as many cores	06:48:46
dramforever	well it's literally just better at all regards except price	06:49:00
Tristan Ross	Yeah lol, I can at least use GNOME on it and it's not lagging	06:49:51
Tristan Ross	I was able to play SuperTuxCart just fine	06:50:03
dramforever	currently twiddling thumbs waiting for zhihe a210 and spacemit k3	06:52:56
Tristan Ross	Nice, I wonder what has the most performance in the consumer space	06:54:08
Tristan Ross	I'm looking forward to Tenstorrent's Ascalon, looks interesting but it'll be some time.	06:54:43
dramforever	"consumer"	06:55:02
Tristan Ross	lol, if I can buy it I consider that consumer	06:55:55
vixea	I wish to consume the whole rva23 soc market	07:18:26
vixea	But yea can't wait for Atlantis	07:23:53
vixea	Even if it's the "S"(4 wide) before the changed the image it would seem	07:27:33
vixea	Or at least that's what I'm guessing it's what it is	07:28:03
vixea	* Or at least that's what I'm guessing it's what it is, maybe it's the 6 wide version either way you won't know till it's out anyway	07:28:56
vixea	Oh heh reread the slides it's Ascalon-X	07:30:20
Alex	In reply to @joerg:thalheim.io What's allowed on RISC-V? I haven't done anything outside of M mode, but it seems like the manuals (vol 2 - privileged, chapters 4.3, 4.4, and 4.5) state that pages must be aligned to the page boundary, which is 4 KiB at the smallest level of pages. 0xf000 is appropriately aligned, so I see no reason for the ISA to disallow it. AFAICT there are no ISA-level restrictions on what virtual addresses can be used.	10:43:09
dramforever	fwiw it's basically the same as you would on x86-64, one of 39 bits sign extended / 48 bits sign extended / 57 bits sign extended depending on hw	13:07:40
dramforever	well you don't have 39 on x86-64 but it's fairly easy to extend that down	13:07:52
dramforever	* fwiw it's basically the same as you would have on x86-64, one of 39 bits sign extended / 48 bits sign extended / 57 bits sign extended depending on hw	13:08:00
dramforever	and for linux, "positive" address for user, "negative" for kernel	13:08:23
Tristan Ross	Oh yay, stdenv is built. `$ time nix build .#stdenv real 565m12.113s user 3m55.911s sys 0m32.432s`	17:29:14
13 Nov 2025
dramforever	you have a patience that's beyond my imagination	04:12:30
14 Nov 2025
no-mood	Hi all, I have a few questions on RISC-V cross-compilation in Nix I need a bare-metal RISC-V toolchain (riscv32-none-elf with newlib, not Linux). I'm using `pkgs.pkgsCross.riscv32-embedded.buildPackages.gcc` which provides the correct riscv32-none-elf-gcc. Now: Is `pkgsCross` just syntactic sugar over `crossSystem`, or are there functional differences? For bare-metal embedded: should I use `pkgsCross.riscv32-embedded.buildPackages.gcc` or is there a better package? For context, I'm writing a SpinalHDL/Verilog project, with RISC-V firmware for an FPGA (no OS, pure embedded)	11:49:45
no-mood	* Hi all, I have a few questions on RISC-V cross-compilation in Nix I need a bare-metal RISC-V toolchain (riscv32-none-elf with newlib, not Linux). I'm using `pkgs.pkgsCross.riscv32-embedded.buildPackages.gcc` which provides the correct riscv32-none-elf-gcc. Now: Is `pkgsCross` just syntactic sugar over `crossSystem`, or are there functional differences? For bare-metal embedded: should I use `pkgsCross.riscv32-embedded.buildPackages.gcc` or is there a better package? For context, I'm writing a SpinalHDL/Verilog project, with RISC-V firmware for an FPGA (no OS, pure embedded)	11:49:53
no-mood	* Hi all, I have a few questions on RISC-V cross-compilation in Nix I need a bare-metal RISC-V toolchain (riscv32-none-elf with newlib, not Linux). I'm using `pkgs.pkgsCross.riscv32-embedded.buildPackages.gcc` which provides the correct riscv32-none-elf-gcc. Now: Is `pkgsCross` just syntactic sugar over `crossSystem`, or are there functional differences? For bare-metal embedded: should I use `pkgsCross.riscv32-embedded.buildPackages.gcc` or is there a better package? For context, I'm writing a SpinalHDL/Verilog project, with RISC-V firmware for an FPGA (no OS, pure embedded)	11:50:02
Alex	Answer to 1: yes.	11:50:17
Alex	* Answer to 1: yes, it is just sugar (and `crossSystem` is far more flexible).	11:50:45
Tristan Ross	FAIL: lookup_test ================= AddressSanitizer:DEADLYSIGNAL ================================================================= ==12600==ERROR: AddressSanitizer: SEGV on unknown address 0x100d5554fbe8 (pc 0x7ffff7877a26 bp 0x7fffffffdf60 sp 0x7fffffffd710 T-1) ==12600==The signal is caused by a READ memory access. AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12600) AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12600) FAIL lookup_test (exit status: 133) FAIL: auparse_extra_test ======================== AddressSanitizer:DEADLYSIGNAL ================================================================= ==12629==ERROR: AddressSanitizer: SEGV on unknown address 0x100d5554fbe8 (pc 0x7ffff7877a26 bp 0x7fffffffdf50 sp 0x7fffffffd700 T-1) ==12629==The signal is caused by a READ memory access. AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12629) AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12629) FAIL auparse_extra_test (exit status: 133) Oh no, audit fails to build...	19:04:45

Show newer messages

Back to Room ListRoom Version: 10