So it seems that what could be problematic is not getting it to boot but rather how to get proper graphics support. How difficult would it be to reverse engineer the GPU?
Do we even know how to access the GPU? On x86-based systems there would be a standard bus (PCI/AGP/PCIe) to enumerate the the graphics device, but my impression is ARM doesn't have such things. A lot of the recent improvement in graphics on Linux has come from manufacturers deciding to become cooperative rather than there being more people reverse-engineering graphics drivers. (Broadcom is contributing support for th…
What isn't always available is a way to dynamically enumerate a device's, uh, device tree. On PCs, this is usually accomplished through ACPI tables, where the bootloader (BIOS or UEFI) populates a table of data and callbacks to AML bytecode functions which the OS kernel can read and eval. [0]
So on x86, the OS finds the PCIe memory mapped addressed in the MCFG table.
On most ARM devices, this data has to be passed to the kernel at runtime, in what Linux calls a "device tree reference", compiled to a "DTB" file.
So, on a UEFI-based ARM system, it should be possible to just insert, say, an AMD graphics card onto the PCIe bus and get a working GPU.
[0] https://www.kernel.org/doc/html/latest/arm64/acpi_object_usa...