This post did not contain any content.
-
This post did not contain any content.
-
This post did not contain any content.
-
@a1ba SBCs are pretty much designed to be unbootable, as none implement a bootable standard like BIOS.
-
@a1ba SBCs are pretty much designed to be unbootable, as none implement a bootable standard like BIOS.@Suiseiseki how about SBCs that have UEFI
-
@Suiseiseki how about SBCs that have UEFI
-
@Suiseiseki @a1ba u-boot gaming@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. -
@a1ba UEFI is not properly standardized and it isn't bootable either - you need GNU GRUB to get something barely acceptable.@Suiseiseki BIOS isn't properly standardized either. It's pretty much x86 specific
-
@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 -
@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. -
@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. -
@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. -
@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. -
@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. -
-
@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. -
-