In reply to @thefossguy:matrix.org
What if, instead of muxing the SD card, there was no SD card on the "carrier board" but it "emulated" one and the SD card is "backed" by an image on disk or a loopback device?

In reply to @ar333:matrix.org
Do you need physical storage? I've had success loading u-boot with sunxi-fel, have u-boot create an ethernet gadget, and load the kernel / initramfs over tftp. The only problem is that sunxi-fel is allwinner only, but I imagine other manufactures have similar tools

Not directly tow-boot, but at least related to my attempt to support the rock4c+:

I'm getting the feeling that the rock4c+ defconfig is plain wrong. I was getting the RD image overlap, so I thought "hey, I know that the rk3399 uboot in nixpkgs works on the sd card, so let's use that one together with the patch from https://github.com/Tow-Boot/U-Boot/pull/3".
So I tried using

nixpkgs.legacyPackages.aarch64-linux.buildUBoot {
  defconfig = "rock-4c-plus-rk3399_defconfig";
  extraMeta.platforms = ["aarch64-linux"];
  BL31 = "${nixpkgs.legacyPackages.aarch64-linux.armTrustedFirmwareRK3399}/bl31.elf";
  filesToInstall = [ "u-boot.itb" "idbloader.img"];
  extraPatches = [
    ./3.patch
  ];
};

Which did not boot due to some problem with __symbols__ within uboot (Saw that a few times while experimenting with tow-boot as well).

Doing the same with defconfig = "rock-pi-4-rk3399_defconfig, the board not only starts u-boot but actually works again with my system...
So while this is not related to tow-boot, I do have the impression that something is off with the device tree or defconfig for the 4c+, which is way over my head to fix

CRTified

nix-build -A [...] --arg configuration '{ Tow-Boot = { buildUBoot = true; uBootVersion = "2023.07"; }; }'

In reply to @luiz.sdf:matrix.org
why no irc bridge? ;-;