| 12 Nov 2025 |
 Tristan Ross | I wonder how fast this'll build | 06:42:09 |
| 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 |
