| 12 Jul 2023 |
 Pratham Patel | I will recheck using the latest stock firmware | 17:38:41 |
 Alex | You might need to flash the latest firmware in the vendor's Debian system.
The "upstream" kernel's DTB has a broken SPI partition table that is too small to flash all of the u-boot file. | 17:38:44 |
| Pratham Patel | I don't understand what you mean by the last sentence... | 17:39:18 |
| Alex | $ cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
mtd0 has a size of 128KiB, but the latest versions of u-boot exceed that. | 17:40:05 |
| Alex | Sorry, I probably should've mentioned this sooner. | 17:40:40 |
| Pratham Patel | That's why I prefer booting from SD Card for development purposes :) | 17:41:09 |
| Pratham Patel | I belive they have switched their priorities to porting EDK2 | 17:41:27 |
| Alex | This isn't a problem on the vendor's Debian, because the devel branch of the kernel has a different partition table. | 17:41:27 |
| Alex | Can you describe what needs to be done to boot from SD?
I might be able to make the change. | 17:41:51 |
| Pratham Patel | Just a sec | 17:42:10 |
| Pratham Patel | I use this partition layout for the first two partitions
https://github.com/thefossguy/archlinux-visionfive2/blob/master/create-image.sh#L85 | 17:42:46 |
| Pratham Patel | Then, you dd u-boot-spl.bin.normal.out to part1 and visionfive2_fw_payload.img to part2 | 17:44:13 |
| Alex | So 4 partitions:
- SPL (u-boot metadata)
- u-boot (flat binary)
- boot (FAT)
- root
Makes sense. | 17:44:29 |
| Pratham Patel | So instead of reading firmware from flash, the firmware is entirely read from the SD card ;) | 17:44:31 |
| Pratham Patel | In reply to @alex:tunstall.xyz
So 4 partitions:
- SPL (u-boot metadata)
- u-boot (flat binary)
- boot (FAT)
- root
Makes sense. Exactly! | 17:44:44 |
| Pratham Patel | But be vary of the sectors where the partions start and end | 17:44:56 |
| Pratham Patel | There's a reason why my script starts the first partition at 4096 ;) | 17:45:19 |
| Alex | Oh does the bootloader expect the partitions to be at specific offsets? | 17:45:20 |
| Pratham Patel | Yes :) | 17:45:48 |
| Pratham Patel | But that's the ZSBL so it won't ever change | 17:46:03 |
| Pratham Patel | That's permanent now. For better or for worse | 17:46:12 |
| Pratham Patel | In reply to @alex:tunstall.xyz
$ cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
mtd0 has a size of 128KiB, but the latest versions of u-boot exceed that. Nothing like this, where the partition table layout breaks ;) | 17:46:46 |
| Pratham Patel | Would it be feasible to create an "installer image" for RISC-V that is similar to what one gets for x86/arm64 from nixos.org? | 18:00:20 |
| Alex | In reply to @thefossguy:matrix.org
Would it be feasible to create an "installer image" for RISC-V that is similar to what one gets for x86/arm64 from nixos.org? It could be, but it wouldn't be very useful considering that building natively would require building 800+ derivations (and I think the kernel alone would need >20GiB of disk space while building). | 18:01:43 |
| Pratham Patel | No community supported caches until RISC-V support is merged in "mainline"? | 18:02:37 |
| Pratham Patel | My current archlinux image uses a binary cache from an arch maintainer. Arch is x86-only, while I belive NixOS isn't x86-only :) | 18:03:30 |
| Alex | It isn't, but NixOS only has official caches for {x86_64,aarch64}-{linux,darwin} | 18:04:19 |
| Alex | In reply to @thefossguy:matrix.org
No community supported caches until RISC-V support is merged in "mainline"? Essentially, community-supported caches are the only option.
Unless someone's already gone to the trouble of building a riscv64 cache, you're out of luck. | 18:05:10 |
 [0x4A6F] | We also need powerful builders to fill these caches... | 18:05:12 |
| Pratham Patel | ah I understand it now | 18:05:40 |
