@a1ba UEFI is not properly standardized and it isn't bootable either - you need GNU GRUB to get something barely acceptable.

@RedTechEngineer @a1ba Yes, u-boot is the problem.

You can't just boot from a flash drive or a CD - you need to prepare a specific configuration of Linux with specific dtbs, a specific initramfs and then also support a cursed partitioning scheme for the GNU.

Booting from a SD isn't that bad, but that has terrible performance - you kind of need to be able to boot from eMMC or a SSD.

@Suiseiseki BIOS isn't properly standardized either. It's pretty much x86 specific

@a1ba There's not much that makes BIOS dependent on x86 and AMD64 - it would be quite easy to have an Aarch64 SoC support BIOS booting of ARM OS's.

@Suiseiseki there is.

Not only you need io ports, though those usually are presented mmio on non-x86 architectures, you also need some interrupt vectors, to act like int 10h on x86.

But what's the point of simulating that if there is UEFI

@a1ba >Not only you need io ports
Standard I/O ports are a good thing and you can just not implement those.

>you also need some interrupt vectors, to act like int 10h
Interrupts are okay and you can just not implement interrupts.

>if there is UEFI
UEFI requires implementing a bunch of things, which is far more complicated than BIOS.

@Suiseiseki but that's the thing with BIOS.

You need int 10h to interact with it, even set up the video mode.

@a1ba You need something similar with UEFI to set the video mode.

Many SBC's don't even have video output, or a reasonable shell - which is a problem.

@Suiseiseki many don't have but also many do have and it's used.

What to do with them?

Read some manuals and get real experience programming computers, dude.

@a1ba I have experience programming real computers - including GNUbooting and ARM stuff really sucks in comparison.

@Suiseiseki installing coreboot fork that somebody else made for you isn't programming.

I mean, you're right about booting on average ARM SoC being bad, but not for the reasons you think it is and especially solutions don't make any sense.

@mia @a1ba @RedTechEngineer >Firmware >Look inside. >Software.
You can just replace the APCI with the APCI implementation in GNUboot on good computers to deal with ACPI problems and not have to deal with dtbs.

@mia @a1ba @RedTechEngineer `flashrom -p internal -w image.bin` or external programming is easier.

@mia @a1ba @RedTechEngineer Porting coreboot and then cleaning the proprietary software out seems extremely hard, but maybe it's easier than getting freedom on a ARM SoC?

@mia @a1ba @RedTechEngineer Having to reverse engineer hardware to turn proprietary drivers into free drivers (and running into copyright issues etc) can be harder than working out how to configure coreboot's build system with the correct options to produce a working image (as there's a free chipset driver and free RAMinit etc already).