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.

In reply to @alex:tunstall.xyz
The official documentation is also missing one critical detail: the partition type IDs.

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.

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?

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=";
            })
          ];
        });

i'm surprised you haven't dealt with zeromq, because nix why-depends says systemd depends on it :

» nix why-depends --derivation nixpkgs#systemd nixpkgs#zeromq
/nix/store/mmxfq68bslpjqki0f7svg31cjv2pnr36-systemd-255.2.drv
└───/nix/store/js89ydnz71fv1kqgn69mm7yqfsw61lpi-iptables-1.8.10.drv
    └───/nix/store/5b85c19psp7km2mvnlwzs0gml93v289x-libpcap-1.10.4.drv
        └───/nix/store/rpgg2wwh745g9y928wb6a2w1gn23g9y1-libnl-3.8.0.drv
            └───/nix/store/hks3p38b5vdjkncdkkrcwjjqlhg1cbs7-graphviz-10.0.1.drv
                └───/nix/store/s5pcbnaqw75bxbyk3hyb2kmjr0b1viab-fontconfig-2.15.0.drv
                    └───/nix/store/q124gz30q037qq5n6vnym3n2gkf6r4n9-dejavu-fonts-minimal-2.37.drv
                        └───/nix/store/rngadqxkfwizz368b9zg3az9ifdgfgsn-dejavu-fonts-full-2.37.drv
                            └───/nix/store/rhw4k7zqgrvw36rz6cq5m6p12afpwc7l-fontforge-20230101.drv
                                └───/nix/store/ir6k22cspdsw25l4jskfrlmymhyr30g5-zeromq-4.3.5.drv

Why? Is there something wrong with zeromq on RISC-V?

I don't seem to have a fix for it and my full system rebuild is complete, so it should work fine.