Conversation
@Suiseiseki how about SBCs that have UEFI
1
0
0
@a1ba UEFI is not properly standardized and it isn't bootable either - you need GNU GRUB to get something barely acceptable.
1
0
0
@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.
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.
2
0
0
@Suiseiseki BIOS isn't properly standardized either. It's pretty much x86 specific
1
0
0
@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.
1
0
0
@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
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
1
0
0
@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.
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.
1
0
0
@Suiseiseki but that's the thing with BIOS.
You need int 10h to interact with it, even set up the video mode.
You need int 10h to interact with it, even set up the video mode.
1
0
0
@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.
Many SBC's don't even have video output, or a reasonable shell - which is a problem.
1
0
0
1
0
0
@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.
What to do with them?
Read some manuals and get real experience programming computers, dude.
1
0
1
@snacks @RedTechEngineer @a1ba The typical sdcard technique of bitbanging over SPI is much slower than a HDD.
Some microsd cards can be good, but most are junk.
Some microsd cards can be good, but most are junk.
1
0
0
@a1ba I have experience programming real computers - including GNUbooting and ARM stuff really sucks in comparison.
1
0
0
@Suiseiseki @RedTechEngineer @a1ba sd cards use the same interface as emmc, if you can use one fast than you can use the other fast. Also you can just buy garbage tier emmc modules too
1
0
0
@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.
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.
0
0
0
mia (developer mode)
mia@shrimptest.0x0.st@Suiseiseki @a1ba @RedTechEngineer ngl i’d rather deal with DTs than buggy ACPI firmware
1
0
1
@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.
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.
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@Suiseiseki @a1ba @RedTechEngineer that’s harder though lol
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@snacks @a1ba @Suiseiseki @RedTechEngineer SD cards are sold with speed classes for a reason. you can get cards that read at 200+ MB/s and have a minimum write speed of 90 MB/s; they’re not even that rare or expensive anymore
1
0
2
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@Suiseiseki @a1ba @RedTechEngineer after you implement firmware support.
1
0
0
@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?
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@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)
2
0
1
@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).
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@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
1
0
0
@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
1
0
0
2
0
0
@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
They published the source code. And there is nothing in between except what's in maskrom
1
0
0
@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.
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.
1
0
0
@Suiseiseki @RedTechEngineer @mia it doesn't change the fact about vendor being unable to write drivers for what they literally made
1
0
0
@a1ba @RedTechEngineer @mia Provided u-boot "sources" often contain object code without source code, or obfuscated sources - but you need to actually be able to read source code to work that out - while most people at most look at a few files and see original u-boot source code and think that's all is well.
A popular thing to make proprietary is RAMinit - often the vendor doesn't even have the source code for the RAMinit - they've just got a proprietary binary from the SoC vendor.
A popular thing to make proprietary is RAMinit - often the vendor doesn't even have the source code for the RAMinit - they've just got a proprietary binary from the SoC vendor.
0
0
0
@a1ba @RedTechEngineer @mia Why would they bother?
The whole idea is that they provide something that barely works and then the device goes out of support in a year and then you need to buy the next model and see if that works better (it works worse).
The whole idea is that they provide something that barely works and then the device goes out of support in a year and then you need to buy the next model and see if that works better (it works worse).
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@Suiseiseki @a1ba @RedTechEngineer like what? i compiled the firmware from source (including the “trusted firmware” bits), schematics are available, the drivers are all mainlined and it needs no blobs
1
0
0
@Suiseiseki @RedTechEngineer @mia like with the whole computer industry, they are not really special in that regard.
0
0
0
@mia @a1ba @RedTechEngineer espressobin seems to use DDR4 - and as far as I'm aware, the only computer with free DDR4 RAMinit is the Talos systems.
USB 3.0 is often implemented with proprietary software too.
The onboard 802.11 a/b/g/n +ac/ 2T2R wifi relies on proprietary software functionality.
It seems to have 4MB of SPI NOR flash, which is a place where proprietary software can go - if there is in fact no proprietary software in u-boot - it always comes on the SBC.
It'll take at least 6 hours to investigate properly.
USB 3.0 is often implemented with proprietary software too.
The onboard 802.11 a/b/g/n +ac/ 2T2R wifi relies on proprietary software functionality.
It seems to have 4MB of SPI NOR flash, which is a place where proprietary software can go - if there is in fact no proprietary software in u-boot - it always comes on the SBC.
It'll take at least 6 hours to investigate properly.
1
1
1
mia (developer mode)
mia@shrimptest.0x0.st@Suiseiseki @a1ba @RedTechEngineer there is no on-board wifi, that’s a mini pcie card
1
0
0
@mia @a1ba @RedTechEngineer Oh that's the "ESPRESSObin Ultra Board".
The site is quite broken; https://espressobin.net/tech-spec/
The site is quite broken; https://espressobin.net/tech-spec/
1
0
0
@mia @RedTechEngineer @a1ba Unlike most computers, even the damn Ethernet card on some ARM boards run proprietary software.
On computers, you're typically good unless the NIC is broadcom.
On computers, you're typically good unless the NIC is broadcom.
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@Suiseiseki @a1ba @RedTechEngineer most computers have realtek NICs and those need blobs
1
0
0
@mia @a1ba @RedTechEngineer Realtek NIC's do not need proprietary software although it is available - those run without it.
1
0
1
@Suiseiseki @mia @RedTechEngineer @a1ba
Can confirm, every single Realtek NIC I've owned will bitch and whine about missing proprietary machine code but will work without it anyway.
Can confirm, every single Realtek NIC I've owned will bitch and whine about missing proprietary machine code but will work without it anyway.
1
0
0
@sally @RedTechEngineer @a1ba @mia Linux does the whining and even lies by referring to it as "free".
1
0
0
@Suiseiseki @RedTechEngineer @a1ba @mia
In my cases it lies calling it firmware, not that is free. As a matter of fact I can't recall a single instance of the kernel ever referring to software as free, almost as if the term was deliberately avoided.
In my cases it lies calling it firmware, not that is free. As a matter of fact I can't recall a single instance of the kernel ever referring to software as free, almost as if the term was deliberately avoided.
1
0
0
@sally @RedTechEngineer @a1ba @mia I remember seeing a "missing free firmware" dmesg output years ago, but it seems that message is now removed.
2
0
0
0
0
0
Alexandre Oliva
lxo@snac.lx.oliva.nom.br
gnu linux-libre prints such messages
CC: @RedTechEngineer@fedi.lowpassfilter.link @sally@freesoftwareextremist.com @mia@shrimptest.0x0.st @a1ba@suya.place
CC: @RedTechEngineer@fedi.lowpassfilter.link @sally@freesoftwareextremist.com @mia@shrimptest.0x0.st @a1ba@suya.place
2
0
2
@lxo @Suiseiseki @RedTechEngineer @mia @a1ba
Ah yeah, now I remember what's going on. Linux-libre does print this when you insert a device that requires proprietary software to work and there's no free replacement available, hence why it says it's missing.
Ah yeah, now I remember what's going on. Linux-libre does print this when you insert a device that requires proprietary software to work and there's no free replacement available, hence why it says it's missing.
1
0
0
@lxo @RedTechEngineer @sally @mia @a1ba That message doesn't seem correct for say r8169, as https://packages.debian.org/bullseye/firmware-linux-free doesn't include realtek software and https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.r8169
0
0
0
@sally @lxo @RedTechEngineer @a1ba @mia Ah yes, we've run into grammatical ambiguity.
"missing free firmware" could mean that there's free software, but it's missing, or that free software is missing.
"missing free firmware" could mean that there's free software, but it's missing, or that free software is missing.
2
0
1
@sally @RedTechEngineer @a1ba @lxo @mia I would personally write; "Free peripheral software replacement missing".
0
0
0
RedTechEngineer
RedTechEngineer@fedi.lowpassfilter.link
@Suiseiseki @sally @mia @lxo @a1ba no free software permitted, please retain your shackles.
buy new product.
buy new product.
0
1
2