move WIP u-boot modifications in libre-testing

I asked bill-auger to push his modifications so he uploaded the
packages to libre-testing and the PKGBUILD modifications to abslibre.

Since the pakcages have been uploaded to libre-testing it's better to
move them here.

While the code is not ready yet, it enables users to test the new
u-boot which fixes the Ethernet PHY. From linux-sunxi we have[1]:
    Proper fix for rev. F and newer is to apply trace length
    compensation at the PHY.

    This is done by default (also for rev. H and newer despite commit
    message mentioning only realtek not Micrel) since mainline linux
    v5.15 and since mainline u-boot v2022.04;

[1]https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#calibrate_at_PHY

That page also has more background on the issue being fixed here
(basically making all the various Lime 2 A20 revisions (which have
different Ethernet PHY) work with the same u-boot binary / package.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

1 files changed, 39 insertions, 0 deletions

diff --git a/libre-testing/uboot4extlinux-sunxi/TODO.txt b/libre-testing/uboot4extlinux-sunxi/TODO.txt
new file mode 100644
index 000000000..1d8e08c63
--- /dev/null
+++ b/libre-testing/uboot4extlinux-sunxi/TODO.txt
@@ -0,0 +1,39 @@
++------+
+| TODO |
++------+
+- We could add automatic updates. It would require a bit of
+  work:
+  - u-boot has code to detect images. We could write a tool that
+    reuses that code to detect Allwinner eGON images.
+    See the 0001-Add-tool-to-dump-sunxi-images.patch for inspiration
+    on how to do that.
+  - Once done that tool could then be leveraged for detecting
+    u-boot installations and updating the u-boot images with a
+    pacman hook for devices that are booted.
+  - We could also check the devicetree to make sure we are
+    running on the right device.
+  - For chroots we could somehow detect that we are in a chroot
+    and find if there is an underlying block device, and upgrade
+    u-boot there.
+  - In any case we need to be careful not to break other computers:
+    some x86 laptops have eMMC too, and most of the time theses
+    eMMC also contains the BIOS and/or UEFI, so we don't want to
+    erase that. We also don't want to erase the laptop filesytems
+    either.
+- We need to build some infrastructure for users to report working
+  boards and mention it here and on the wiki for adding official
+  support for boards. We could for instance do something as simple
+  as possible like open a new bug tracker specially for that and
+  just reference that in the wiki for instance.
+- We also need to make dtb fragment work in u-boot to support more
+  use cases and possibly also package popular dtb fragment for the
+  beaglebone black.
+- In addition we could then leverage that to build an image for
+  the beaglebone black (or other boards) for flashing Libreboot.
+  This way Libreboot would benefit from an FSDG compatible image
+  that is also maintained by an upstream distribution.
+- We could also look maing an u-boot package that has UEFI compatibility
+  and also bundle GRUB with it. This way we could simplify the installation
+  instructions by leverage users knowledge about GRUB and also potentially
+  investigate if we could leverage the UEFI standard for easily upgrading
+  that u-boot+UEFI+grub image.