| 8 Apr 2024 |
 Alex | In reply to @thefossguy:matrix.org
using the vendor's recovery tool To elaborate: as long as you have access to UART, you can't brick your system because the ZSBL is also capable of loading the next stage directly over UART. | 08:37:21 |
 @cnx:loang.net | thanks, that's good to know | 08:37:44 |
| Alex | In reply to @thefossguy:matrix.org
best not to try it, and remain sane :) Well I've already reverse engineered some of the ZSBL code, so I'm not sure what sanity I have left... | 08:38:10 |
| @cnx:loang.net | In reply to @thefossguy:matrix.org
ZSBL is in SoC's ROM. That has an offset to look for, where OpenSBI is stored. OpenSBI either has a hardcoded offset that it looks for, to load U-Boot, or you can specify one at build-time (IIRC, the later is done for the VF2) and then U-Boot scans storage mediums in the given order and scans for EFI partitions and loads from the first match. if the opensbi offset is fixed does it mean you need to flash the partition table along with it? | 08:40:14 |
 Pratham Patel (you can mention me) | In reply to @cnx:loang.net
if the opensbi offset is fixed does it mean you need to flash the partition table along with it? this is selected at compile-time for the VF2 | 08:40:44 |
| @cnx:loang.net | I meant the offset to find opensbi | 08:41:04 |
| Pratham Patel (you can mention me) | I'm not sure if I follow what you mean by the question "flash the partition table along with it" | 08:41:47 |
| Pratham Patel (you can mention me) | flash the SPI flash's partition table? | 08:41:59 |
| Pratham Patel (you can mention me) | that reminds me | 08:42:05 |
| Pratham Patel (you can mention me) | you can just switch the DIP switches to tell ZSBL (not tell, more like electrically change path; but same thing) to load OpenSBI+U-Boot from the eMMC/SD. | 08:42:54 |
| Pratham Patel (you can mention me) | that way, you an keep the SPI intact and experiment by keeping opensbi and uboot on the SD/eMMC | 08:43:21 |
| @cnx:loang.net | In reply to @thefossguy:matrix.org
flash the SPI flash's partition table? i was still on the bootloader on emmc train of thought, i.e. if i want to partition the emmc manually, i suppose i need to flash an image with opensbi and u-boot first, or do i have to build a whole system image then resize | 08:43:40 |
| Pratham Patel (you can mention me) | you can partition it manually and flash both components individually :) | 08:45:32 |
| Pratham Patel (you can mention me) |
- create partitions
- assign "partition type"
| 08:48:20 |
| @cnx:loang.net | thanks, i found the expected layout for sdio here: https://hill9.org/journal/2023/08/08/risc-v-debian-ubuntu-and-fedora-linux-on-visionfive-2/ | 08:58:36 |
| @cnx:loang.net | hmmm weird partion 1 and 2 here are half-ish the size of the one in arch's script | 09:02:04 |
| Alex | This can also be found in the vendor's official documentation: https://doc-en.rvspace.org/VisionFive2/Boot_UG/JH7110_SDK/boot_address_allocation.html
Now whether or not those offsets are important is still unknown.
Note that partitions 1 and 2 are now "reserved"; this is because the vendor at some point changed their mind and now only wants to support booting from flash and booting from UART.
But SDIO and eMMC boot still work AFAIK. | 09:34:00 |
| Alex | The official documentation is also missing one critical detail: the partition type IDs. | 09:35:38 |
| @cnx:loang.net | thanks! | 09:37:28 |
| Pratham Patel (you can mention me) | In reply to @alex:tunstall.xyz
The official documentation is also missing one critical detail: the partition type IDs. do you mean these?
https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html#flashing | 09:38:33 |
| Alex | Yes, those typecode UUIDs for partition 1 and 2 are necessary. | 09:39:15 |
| Pratham Patel (you can mention me) | i usually never go back to vendor docs once upstreaming starts :) | 09:39:54 |
| Alex | I'm quite thankful that they at least have some documentation.
Not everyone wants to read Linux kernel code and dts files to figure out where the UART device and SRAM are. | 09:42:10 |
| Pratham Patel (you can mention me) | They ought to have at least this much provided | 09:42:36 |
| Alex | They have a (nearly) complete description of the entire physical memory map.
If only I could remember which document it's in... | 09:43:17 |
| Pratham Patel (you can mention me) | Yeah, JH7110 is surprisingly "open". | 09:43:44 |
| Alex | Here it is: https://doc-en.rvspace.org/JH7110/TRM/JH7110_TRM/system_memory_map.html | 09:44:09 |
 Steven Keuchel | In reply to @alex:tunstall.xyz
I've measured ~22h for building an unregisterised GHC 9.2.8 booted via an unregisterised GHC 8.10.7 when running on VF2 (JH7110 SoC).
(Default flavour with profiled libraries, dynamic libraries, and documentation enabled.)
One minor difference to a typical RV64GC build is that I also enable Zba and Zbb.
I have no idea what performance impact this has on my hardware.
That a Milk-V Pioneer would take over 30h to do the same is surprising. I was usually also compiling something else. I think the registerised ones are more accurate. | 09:58:10 |
| Steven Keuchel | In reply to @alex:tunstall.xyz
I'm getting the following error when trying to build certain Haskell packages with a registerised GHC.
Couldn't find a target code interpreter. Try with -fexternal-interpreter
I thought registerised GHC included TemplateHaskell support?
Steven Keuchel do I need the patches that enable GHCi for this to work? yes exactly, you need https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10714 and https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12286 | 09:59:04 |
| Steven Keuchel | I wanted to create a nixpkgs PR once the the second one is merged upstream. | 09:59:53 |
