| 10 Apr 2024 |
 sorear | actually that probably doesn't help because they're probably big enough that the silicon teams don't talk to the ISA experts | 04:12:28 |
 Pratham Patel (you can mention me) | we'll see the real deal when upstreaming starts and they need to disclose the erratas | 04:12:58 |
 Alex | In reply to @thefossguy:matrix.org
misuzu: is there any reason why you are using the vendor kernel? AFAIK, everything but PCIe (for a headless build box) has been merged upstream. Or did I just answer myself with "PCIe isn't yet in upstream?" Unless it's been integrated in the past week, mainline also appears to be missing the PLL0 patch needed for running the CPU at 1.5 GHz instead of 1 GHz. | 08:23:01 |
 @cnx:loang.net | In reply to @thefossguy:matrix.org
misuzu: is there any reason why you are using the vendor kernel? AFAIK, everything but PCIe (for a headless build box) has been merged upstream. Or did I just answer myself with "PCIe isn't yet in upstream?" is pcie required for nvme? | 08:24:23 |
| Pratham Patel (you can mention me) | In reply to @alex:tunstall.xyz
Unless it's been integrated in the past week, mainline also appears to be missing the PLL0 patch needed for running the CPU at 1.5 GHz instead of 1 GHz. A v4 was sent today morning | 08:24:53 |
| Alex | In reply to @cnx:loang.net
is pcie required for nvme? I'd be very surprised if it isn't. | 08:25:00 |
| Pratham Patel (you can mention me) | In reply to @cnx:loang.net
is pcie required for nvme? NVMe is over PCIe, so yes | 08:25:31 |
| Pratham Patel (you can mention me) | In reply to @thefossguy:matrix.org
A v4 was sent today morning A v5 will happen but that should be the final one.
https://lore.kernel.org/linux-riscv/20240410033148.213991-1-xingyu.wu@starfivetech.com/T/#mc21269f266c6a7207416d57c98d5f4d64d46cf89 | 08:39:07 |
|  ohyeah joined the room. | 18:31:00 |
 misuzu | In reply to @thefossguy:matrix.org
misuzu: is there any reason why you are using the vendor kernel? AFAIK, everything but PCIe (for a headless build box) has been merged upstream. Or did I just answer myself with "PCIe isn't yet in upstream?" yep | 19:52:45 |
| 14 Apr 2024 |
|  hxr404 ✨ [they/them] (offline) changed their display name from hxr404 ✨ [they/them] (offline) to hxr404 ✨ [they/them]. | 15:30:58 |
| 15 Apr 2024 |
|  @nscnt:matrix.org joined the room. | 10:08:49 |
| @nscnt:matrix.org left the room. | 17:37:55 |
| 16 Apr 2024 |
 Dagn Hive | was trying to compile zeromq so i could confirm the build failure on master but libuv has literally been taking 4 days to build | 21:20:40 |
| Dagn Hive | i have no idea why it's taking so long, it's hever taken me that long to build before | 21:20:55 |
| Dagn Hive | begining to think it's a lost cause at this point | 21:21:09 |
| Dagn Hive | what's perplexing to me, is that the build phase took less than a day, and the check phase was taking almost 5 days before i cancelled it | 23:45:37 |
| Dagn Hive | * what's perplexing to me, is that the build phase took less than a day, and the check phase was taking almost 4 days before i cancelled it | 23:45:52 |
| Dagn Hive | ok i ran the build again, and this time the build failed after 20 minutes, so clearly the first time was a weird fluke | 23:56:51 |
| 17 Apr 2024 |
 silvanshade | I created a nix flake with overlays for gcc and clang with xtheadvector support. Maybe interesting for some people to experiment with. https://github.com/milkv-community/nixpkgs-xthead-toolchains | 12:02:29 |
| Alex | I tried updating my VF2 to latest nixos-unstable (as of ~1 week ago) and now it won't boot...
Unhandled exception: Instruction access fault
EPC: ffffffa700140304 RA: 00000000cb55d034 TVAL: ffffffa700140304
EPC: ffffffa67359d304 RA: 000000003e9ba034 reloc adjusted
(Then a dump of the registers.)
It seems like there's something wrong with the bootloader on the EFI partition.
Switching back to the bootloader of the previous version worked.
Change that broke the system: https://github.com/AlexandreTunstall/nixos-riscv/commit/b50ef62175853684441a9e312aa12218f5be79d3
Good Nixpkgs revision: 2726f127c15a4cc9810843b96cad73c7eb39e443
Bad Nixpkgs revision: 4cba8b53da471aea2ab2b0c1f30a81e7c451f4b6
Has anyone else booted such a recent Nixpkgs version? | 22:10:19 |
| Alex | (I did try reformatting the boot partition several times and checking for Nix store corruption. Neither of those resolved the issue.) | 22:32:49 |
| 18 Apr 2024 |
| @nscnt:matrix.org joined the room. | 13:20:59 |
 Mic92 | Steven Keuchel: Do you have some configuration for booting with EFI? I think I flashed edk2 correctly but it's hard to verify without any graphical output. I have the NixOS image you provided on the sd card and the original fedora on the NVME. In theory the Fedora should also boot with EFI because it has a efi grub binary. Removing the SD-card however will result in nothing to happen. | 13:24:11 |
| Mic92 | The early boot with the SD card looks like this:
SOPHGO ZSBL
sg2042:v0.3
sg2042 work in single socket mode
chip0 ddr info: raw data=0x5050505,
ddr0 size:0x800000000
ddr1 size:0x800000000
ddr2 size:0x800000000
ddr3 size:0x800000000
SD initializing 100000000Hz (transfer frequency at 25000000Hz)
sd card init ok
0:riscv64/conf.ini file size is 160
read config from sd
rv boot from sd card
SD initializing 100000000Hz (transfer frequency at 25000000Hz)
sd card init ok
0:riscv64/fw_dynamic.bin file size is 534720
0:riscv64/riscv64_Image file size is 26265600
| 13:30:14 |
 Steven Keuchel | You don't get any output from the zbsl without the SD card? This indicates that something is wrong with the firmware in the SPI. To figure out what is going wrong exactly you would need to get the output of the tf-a, i.e. the boot stages before the zsbl. | 13:54:38 |
| Steven Keuchel | You can also EFI boot using LinuxBoot, that's at least how their early fedora images did it. | 13:55:45 |
| Steven Keuchel | Did you flash edk2 to SPI or to SD? | 13:56:40 |
| Mic92 | Steven Keuchel: ok. So I would flash their LinuxBoot to SPI and than use grub with efi support? | 13:56:45 |
| Mic92 | I flashed to SPI with flashcp | 13:56:52 |
