| 8 Apr 2024 |
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 |
Steven Keuchel | be careful though, one has to be added to the hadrian derivation and the other to the ghc derivation | 10:00:31 |
Alex | Well damn, I'm already 3h into a build with both on the GHC derivation 🙃
I assume your Hadrian PR goes into the Hadrian derivation? | 10:01:49 |
Steven Keuchel | here is the part of my overlay that does this
ghc964 =
let
override1 = super.haskell.compiler.ghc964.override {
bootPkgs = self.haskell.packages.ghc963Binary;
};
override2 = override1.override {
hadrian = override1.passthru.hadrian.overrideAttrs (oldAttrs: {
patches = (oldAttrs.patches or [ ]) ++ [
./patches/hadrian-9.6.4-allow-Cabal-3.10.patch
# https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10714
(super.fetchpatch {
url = "https://gitlab.haskell.org/ghc/ghc/-/commit/dd38aca95ac25adc9888083669b32ff551151259.patch";
hash = "sha256-xqs6mw/akxMy+XmVabACzsIviIKP4fS0UEgTk0HJcIc=";
stripLen = 1;
})
];
});
};
in
override2.overrideAttrs (oldAttrs: {
patches = (oldAttrs.patches or [ ]) ++ [
# https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12286
(super.fetchpatch {
url = "https://gitlab.haskell.org/ghc/ghc/-/commit/c5e47441ab2ee2568b5a913ce75809644ba83271.patch";
hash = "sha256-t3KkuME6IqLWuESIMZ7OVAFu7s8G+x0ev+aVzBUqkhg=";
})
];
});
| 10:02:15 |
Alex | Your hash for 10714 doesn't match mine... Is that commit still fetchable? | 10:05:17 |
Steven Keuchel | grr, I hate fetchpatch | 10:05:58 |
Steven Keuchel | let me gc and try to fix it | 10:06:08 |
Alex | I'm fetching the entire MR, so that might be why (but the other one matches) | 10:08:12 |
Alex | Yep, build fails with your hash.
Correct one is sha256-uonXubXjMywSbUe/p2HLIWXDpwLWHlpZDMBvDnr/Utc= | 10:14:13 |
Alex | Oh wait, I was missing stripLen. Nevermind. | 10:17:10 |