NixOS RISC-V - Public Room Timeline

	NixOS RISC-V	207 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	64 Servers

Load older messages

Sender	Message	Time
12 Nov 2025
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
Tristan Ross	(This is native btw)	19:04:52
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's tests fail...	19:05:11
15 Nov 2025
Tristan Ross	https://github.com/linux-audit/audit-userspace/issues/504#issuecomment-3535532063 Wouldn't the AddressSanitizer: "CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0)" be an internal assertion failure within ASAN? The suppression_ctx (suppression context) pointer is null when it shouldn't be, causing ASAN to crash while trying to handle a memory error. Recommend not using ASAN in the build process until it's support is better. Check for compiler issues around ASAN on RISC-V. Let "make check" run without ASAN and see if it passes. Hmm, how do you even turn off ASAN?	03:53:04
dramforever	Tristan Ross: audit unconditionally enables asan if found	03:58:31
Tristan Ross	Oh	03:58:43
dramforever	in configure.ac	03:59:09
Tristan Ross	Also, I noticed there's a `--with-riscv` option in audit that we can enable lol	03:59:11
Tristan Ross	Yeah, I'm trying to turn that off	03:59:24

Show newer messages

Back to Room ListRoom Version: 10