This post did not contain any content.
-
@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. -
-
-
-
@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?@Suiseiseki @a1ba @RedTechEngineer nah. the real problem with those is just device drivers (and the terrible quality of vendor drivers that end up in the kernel tree)
-
@Suiseiseki @a1ba @RedTechEngineer nah. the real problem with those is just device drivers (and the terrible quality of vendor drivers that end up in the kernel tree)@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).
-
@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).@Suiseiseki @a1ba @RedTechEngineer idk i fixed the DTBs for the specific board revision of an espressobin that i had, and did some work to get the internal ethernet switch to init properly (i.e. not bridging WAN and LAN at bootup). that was not hard at all
-
@Suiseiseki @a1ba @RedTechEngineer nah. the real problem with those is just device drivers (and the terrible quality of vendor drivers that end up in the kernel tree)@mia @Suiseiseki @RedTechEngineer I love installing vendor fork of linux 4.19 with broken drivers for all IP blocks made by them in house in 2025
-
@Suiseiseki @a1ba @RedTechEngineer idk i fixed the DTBs for the specific board revision of an espressobin that i had, and did some work to get the internal ethernet switch to init properly (i.e. not bridging WAN and LAN at bootup). that was not hard at all
-
@Suiseiseki @RedTechEngineer @mia does vendor's u-boot and atf forks can be considered proprietary software?
They published the source code. And there is nothing in between except what's in maskrom -
@mia @Suiseiseki @RedTechEngineer I love installing vendor fork of linux 4.19 with broken drivers for all IP blocks made by them in house in 2025@a1ba @RedTechEngineer @mia Imaginary property does not exist; https://www.gnu.org/philosophy/not-ipr.html
Vendors have broken drivers for peripheral devices and even the main SoC - with the only property being you being property of the vendor if it's proprietary. -
@a1ba @RedTechEngineer @mia Imaginary property does not exist; https://www.gnu.org/philosophy/not-ipr.html
Vendors have broken drivers for peripheral devices and even the main SoC - with the only property being you being property of the vendor if it's proprietary.@Suiseiseki @RedTechEngineer @mia it doesn't change the fact about vendor being unable to write drivers for what they literally made
