@a1ba SBCs are pretty much designed to be unbootable, as none implement a bootable standard like BIOS.

@Suiseiseki @a1ba u-boot gaming

@Suiseiseki how about SBCs that have UEFI

@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?