non-x86 open-source-hardware laptops, let's take stock of March 2024

[DiTBho]

Preamble
So, after dropping the bombshell "we made THE definitive risc-v laptop" (see here), to raise money from pre-sales, no one saw anything ("officially released", lol), and I think the "ROMA" laptop is just another one is vaporware marketing garbage.

It's easy to think of throwing a CM4 or an RPI into a box (I've also seen wooden ones), throwing in a wireless keyboard... but what comes out is NOT a laptop!

A laptop must care about the design, in terms of ergonomics, robustness, possibility of putting it in a backpack without it breaking, rather than the commercial nonsense (e.g. mnt Reform, which is also too bloody expensive! >> 1200 euro) of wanting to make it "strange" because it is "Open{ Software, Hardware }".

When you install GNU/Linux on a Thinkpad you don't care if you don't have the firmware sources or the motherboard wiring diagram. You care more that your wrists don't hurt, and that the laptop weighs little and doesn't break easily.

However, putting Coreboot on the Thinkpad x2*0 flash (replacing the IBM/Lenovo firmware) doesn't automatically make it an "Open Hardware laptop", at most... you have opensource firmware, which launches an opensource kernel running an openssource rootfs.

Which is great, but makes sense if you want to spend little and have a more or less open system.

... wanting to work on something completely free from past legacy (Wintel), free to evolve, and for which one can have all the technical documentation without having to do reverse engineering, well ..

Simple criterion
(not considering { ergonomics, robustness, ... } )

Code: [Select]

boolean_t is_ok(x)
{
     ans = True;
     ans = ans logicalAnd x'( CPU.ISA isNot { x86, amd });
     ans = ans logicalAnd x has "{ firmware, hardware } documentaton";
     ans = ans logicalAnd x has "enough RAM and CPU speed to run { emacs, gcc, gdb, x11|twm, ... }";
     ans = ans logicalAnd x has "built-in display{ 800x600|4:3, 1024x768|4:3, ... }";
     ans = ans logicalAnd x has "QWERTY keyboard";
     ans = ans logicalAnd x has "built-in { trackpad, trackball, trackpoint, ... }";
     ans = ans logicalAnd x is "battery powered";
     ans = ans logicalAnd x is "able to work for at least 6 hours on battery";
     ans = ans logicalAnd x has "linux support";

     return ans;
}

gets this list of things, some make sense, others less (and cost too much) 

• Lichee Console 4A, Portable RISC-V Development Terminal (7" (1)), see here
• Lichee Pad Max 4A (14"),  see here
• DevTerm (RISC-V) Kit R-01, see here
• mnt Reform, see here
• Olimex' Teres-v1.0 aka "A64" (we are discussing Teres-v1.5 and v2.0, see here
• PineTab, tablet with detachable backlit keyboard, see here
  (and here the RISC-V version)
  
• PineBook/Pro, see here

edit:
(1) The text console cannot be used "as is" because the LCD display is rotated. X11 can solve this problem easily.
edit2:
list[]+=PineTab

The Apple Macbook Air { M2, M3 } has full linux support now, see here), but ... but all existing documentation comes not from Apple but from reverse engineering.

[brucehoult]

> able to work for at least 6 hours on battery

That disqualifies my brand new 16" Lenovo. Maybe 3.5 hours, max.

Roma shipped in October or November 2023. I know people who have one. They're a ridiculous price for the CPU speed, but then presumably most of the price is made up of the screen, trackpad, battery, chassis etc not the CPU.

You left off PineTab-V, which meets all your stated criteria (except maybe battery life).

[DiTBho]

You left off PineTab-V, which meets all your stated criteria (except maybe battery life).

Code: [Select]

is_ok(PineTab-V) = False;

     x has "QWERTY keyboard"; ---> False
     x is "able to work for at least 6 hours on battery"; ---> False

It's not a laptop, but rather a tablet with an external keyboard -> bad design 

[brucehoult]

You left off PineTab-V, which meets all your stated criteria (except maybe battery life).

Code: [Select]

is_ok(PineTab-V) = False;

     x has "QWERTY keyboard"; ---> False
     x is "able to work for at least 6 hours on battery"; ---> False

It's not a laptop, but rather a tablet with an external keyboard -> bad design 

It's only a difference from whether you unfold the keyboard from the screen/CPU/battery unit, or unfold the screen from the keyboard/CPU/battery unit. The functionality is the same and meets all your previously-stated criteria.

[DiTBho]

no, it does not. Bult-in keyboard is a completely differnt thing in practice.

[langwadt]

no, it does not. Bult-in keyboard is a completely differnt thing in practice.

what's the big difference?

[DiTBho]

here (page 1) I recommend to avoid SoCs made by Allwinner, because they not only mess things up with kernel, dts, firmware, etc., but they sometime release chips with hardware bugs, and worse doesn't even fully comply with Open Source licenses!

Rockchip is a better company, and, in my opinion, the RK3328 is decent enough to be called "better".

I said "hardware bugs" because I am working with { Neo, NeoAir } SBCs ( Allwinner ARM/32bit SoC) ... and umm, inside the SoC there is a buggy "OpenRisc" MPU, which has so many serious hardware bugs that, not only can it not be programmed in C because it requires manual programming in assembly to work-around its bugs (when it is possible, of course), but for safety it ends up that it is better to force it into perpetual iddle because if it were going crazy it could potentionally access all of the SoC's RAM with catastrophic consequences.

That OpenRisc MPU is that part - like in Allwinnder A64 (ARM/64bit SoC) used for the Teres-1 laptop - of hardware responsible for energy management, suspend, etc. It's not at all nice to have hardware bugs in such a delicate component when it comes to battery-powered mobile devices!

- -

Umm, here it is: feel free to list the best ARM alternatives. Perhaps they will be considered for the next Teres laptop.

[DiTBho]

no, it does not. Bult-in keyboard is a completely differnt thing in practice.

what's the big difference?

A built-in keyboard is typically less flexible than folding ones (especially if detacable folding ones) and offers much better typing comfort, and being usually based on a wired-protocol instead of wireless one (Bluetooth) is better from both firmware and kernel perspective, as it makes the developer's life easier and doesn't even bore you with charging extra batteries.

[Infraviolet]

The trouble is that almost no-one wants a non-x86 laptop. Virtually all the programs one is actually running on a laptop are compiled for x86, that includes Windows executables, Windows executbles that run happily under Wine and Linux native executables. With open-source software one can compile it for non-x86 hardware, in theory, but in practice this is a nightmare so all the users just want pre-compiled binaries, and pre-compiled binaries are always set up for x86. Furthermore a lot of software people actually use is legacy software, for which all they have is working executables and an installer executable, many such pieces of software have been long abandoned by their producers and source code for them may well have all been lost by the software's creators at this point. In short, for a laptop to be useful as an all round machine to most users, it must be able to run x86 compiled binaries. As a Linux user and a believer in the spirit of open-source and making-sure-one's-hardware-is-self-repairable-and-not-backdoored I can well get behind the idea of an open-source laptop, but or an open-source laptop to succeed it must support x86. If that means reverse engineering x86 before an open-source implementation can be made, then that is where such efforts need to start, without x86 support the good intentions of an open-source laptop project just cannot meet the practical needs of real users*.

*yes one might note that Apple has gone away from x86 without losing "users", but Apple users are more like fashion consumers than real geeks. Apple having moved away from x86 isn't a relevant comparison, as the trendy wants of Apple buyers are very different than the technical needs among the type of people who would be interested in an open-source laptop as a real daily driver machine.

[brucehoult]

no, it does not. Bult-in keyboard is a completely differnt thing in practice.

what's the big difference?

A built-in keyboard is typically less flexible than folding ones (especially if detacable folding ones) and offers much better typing comfort, and being usually based on a wired-protocol instead of wireless one (Bluetooth) is better from both firmware and kernel perspective, as it makes the developer's life easier and doesn't even bore you with charging extra batteries.

Here is my PineTab-V next to a MacBook.

To answer your objections:

- the keyboard / trackpad unit is quite rigid. Perhaps I would not want to use it on my lap, but on any firm surface it is fine

- it's a little under standard key spacing, but the keys themselves are the same as on anything else these days

- There is a wired plug&socket connection to the CPU/screen unit. The KB can be detached, but you would not normally do so, instead folding it behind the screen if you want to use it as a tablet.

- there are no batteries in the KB/trackpad unit. It is powered by the tablet.

Incidentally, I virtually always use a Microsoft 850 wireless keyboard and mouse on my desktop computers. That uses a dongle plugging into a USB port and, as far as I'm aware, looks to the OS the same as wired USB KB&mouse.

[brucehoult]

The trouble is that almost no-one wants a non-x86 laptop. Virtually all the programs one is actually running on a laptop are compiled for x86, that includes Windows executables, Windows executbles that run happily under Wine and Linux native executables.

Speak for yourself. I have never in my life owned an MS-DOS or Windows computer [1] and I've been using computers since 1980.

*yes one might note that Apple has gone away from x86 without losing "users", but Apple users are more like fashion consumers than real geeks. Apple having moved away from x86 isn't a relevant comparison, as the trendy wants of Apple buyers are very different than the technical needs among the type of people who would be interested in an open-source laptop as a real daily driver machine.

Bull shit.

Go into any tech company where highly skilled programmers are allowed a choice of computer to use, and the vast majority choose Mac, especially if the provided machines are laptops as they typically are these days (with docking to large screen, KB, etc when you are at your desk).

This was true at Mozilla in 2009. It was true in SiFive (RISC-V CPU designer) in 2019. It's true in FaceBook and Google.

Employees at these companies aren't "real geeks"? Don't make me laugh.

[1] ok, I've owned a 24 core i9-13900HX Lenovo with Windows 11 for about the last two weeks and haven't yet gotten around to wiping that and putting Linux on it natively. But I plan to.

[Infraviolet]

I've been on Linux with every computer I've used since 2017, nonetheless the majority of programs I use are precompiled x86 binaries.

[brucehoult]

I've been on Linux with every computer I've used since 2017, nonetheless the majority of programs I use are precompiled x86 binaries.

The majority of programs I use on my arm32, arm64, and riscv64 Linux boards are also precompiled binaries. Binaries for Arm and RISC-V, not for x86, of course. "sudo apt install foo". Boom!

[Veteran68]

*yes one might note that Apple has gone away from x86 without losing "users", but Apple users are more like fashion consumers than real geeks. Apple having moved away from x86 isn't a relevant comparison, as the trendy wants of Apple buyers are very different than the technical needs among the type of people who would be interested in an open-source laptop as a real daily driver machine.

This too is a myth. Have you been to many Linux conferences? My first was RedHat Summit 2013. I thought I would be in the minority with my shiny new 2012 MacBook Pro, expecting most to be running Thinkpads with Linux. But was astonished that probably 75% of attendees, including the graybeards, and about 90% of Red Hat employees, were running MacBooks with RHEL in a VM. Macs are very common in the commercial geek world. I've been to several conferences since and the trend continues.

[SiliconWizard]

Macs are also ubiquitous in the academic world.

[Infraviolet]

"Macs are also ubiquitous in the academic world."
From my observations that's more among humanities academics, and professors who've risen to such a seniority that they don't do any actual research any more but spend all their time forced in to administrative roles for their departments. That is to say, not the sort of academics who are actually doing much hands-on technical stuff.

I'm surprised about your observation about Linux conferences though, seems pretty odd that Linux developers would prefer to have it in a VM than as their base operating system.

[DiTBho]

I've been on Linux with every computer I've used since 2017, nonetheless the majority of programs I use are precompiled x86 binaries.

I've been on GNU/Linux with every computer I've used since 2005, the turning point, from BeOS-v5+netbone  to GNU/Linux (kernel 2.4), on the occasion of the launch of the first beta version of Gentoo!

Since then, from PowerPC-750 to POWER9, from PXA (intel ARM) to Ampere/ARM64, from MIPS-1 to MIPS32R2 (1), but also HPPA (2), nonetheless the majority of programs I use are locally - in house - compiled sources!

When I was a student I compiled things on my laptop, or directly on the router; to compile OpenOffice on a PPC 750@400Mhz/64Mbyte ram took a week, and to compile a tool like "cmake" on an IDT MIPS32@400Mhz/64Mbyte ram took 98hours.

Today I compile whole stage1-3-4s on Qemu/$arch instances created specifically for Catalyst; here I could improve the building system, as it's a cluster of two/three Mac-Mini intel 2009  ... a modern Xeon server would be insanely better.

So I can say that it's just a matter of available computer-power, electricity and personal time (to learn stuff and maintain stuff), not only to compile things, but also to fix them, fix bugs, both in the code and in the ebuilds, or to create the ebuilds themselves, but supporting systems entirely opensource has been widely viable for ~20 years!.

(1) this was/is *very* difficult to be supported a common rootfs, as everything, including critical parts, was/is experimental, therefore untested/bugged
(2) this is *very* difficult (practically impossible?) to be supported for { llvm/clang, Go, Rust, GNAT, ... }

[DiTBho]

I've been on Linux with every computer I've used since 2017, nonetheless the majority of programs I use are precompiled x86 binaries.

The majority of programs I use on my arm32, arm64, and riscv64 Linux boards are also precompiled binaries. Binaries for Arm and RISC-V, not for x86, of course. "sudo apt install foo". Boom!

which kind of binaries?
On my boss's

• Mac-Mini { PPC, intel } cluster
• Ampere servers
• IBM POWER workstations

{ firmware, kernel, userspace, applications } are 100% OpenSource and/or things that we develop in house

Lucky people 

On the contrary, on my MacBook Air I only had commercial software, starting with FinalCut.

In Teres-1 support, as far as I'm concerned, the firmware is uboot, the kernel is linux , the rootfs is based on Catalyst, therefore derived from Gentoo/ARM64, everything is 100% open source.

On the kernel side, there's only the bad GPU issue, because turbofb doesn't work well yet, let's say it "somehow works" (closed hardware), then there's the OpenRISC issue, that little MPU that manages the "energy" matters of the SoC  and that's a long and unclear story on Allwinner's part.

[DiTBho]

To answer your objections:

ok, you convinced me. I'll add it to the list above 

[DiTBho]

The trouble is that almost no-one wants a non-x86 laptop. Virtually all the programs one is actually running on a laptop are compiled for x86

Umm, yup, that's a problem for things like SolidWorks and Avocet compilers.
We solved it in two ways

• for things like SolidWorks: by purchasing an Intel rack server, with integrated KVM. Xen runs Virtual machines, one for every Windows work environment. Applications can also be used via RDP
• for things like Avocet (DOS) compilers: by hacking DosBox for those DOS compilers that were CLI compiled.
  DosBox acts as a bridge between the host machine and its filesystem <--> DOS16 filesystem, and between conio <--> tty;
  It works very well, and compared to Wine it also works on non-x86 hosts. Obviously it has major limitations, but that's how I moved most DOS compilers to the { Ampere, POWER } servers

[DiTBho]

Dunno anything about the Chinese-~MIPS64(1) laptops ... 

(1) ~MIPS64 are not 100% MIPS64-ISA compliant.

[DiTBho]

Video (not my channel, not affilated) "Unboxing RISC-V Lichee Console 4A"

Note, when you boot the kernel, the /dev/tty console is not rotated, so you have to twist your neck
This can be fixed in x11 by rotating the display via software, but that's "no-good" in product design 

[brucehoult]

This is very hard to avoid if you're not a huge manufacturer, as virtually all such small displays are made for portrait mode devices these days. If it bothers you, set it to not display the boot messages.

[DiTBho]

This is very hard to avoid if you're not a huge manufacturer, as virtually all such small displays are made for portrait mode devices these days.

well, I ordered just last week six 10.1" LCDs, besides being 4:3 with a classic LVDS interface they don't have that problem.
It took me two years to find them (paid 60 euro each), but so that they exist - made in 2012 - says the label stuck on the back.

Rather ... the issue is, they use neon lamp (umm typical early 2000s technology here), so they need inverter. This is the only problem, as long as I haven't yet understood how to do it (if it can be done) to make LED-backlighting.

This not only removes a ~pound of weight, but saves energy, making the final device more power efficient.

if it bothers you, set it to not display the boot messages.

I cannot solve the problem by moving the { firmware, kernel } console to the serial as I'm one of those who does not use x11 but only text console, so for me this is something that can't be solved in any way. Except fbcon directly on /dev/fb0

"fbcon" (framebuffer console) is one of my experimental things that does not require X11 to operate, but umm it's not fast, it's rather slow (worse still, software scolling ... d'oh), so ... decent but not brilliant.

[Nominal Animal]

Note, when you boot the kernel, the /dev/tty console is not rotated, so you have to twist your neck

Both uboot and fbcon support console rotation, and adding it to other drivers is not too difficult.

This review included a bootlog, which indicates this verisilicon drm driver (vs-drm) is used, and it does support rotation, but as of kernel 6.8, has not been included in the vanilla kernel yet.  The latest version of the patchset is v3, but Keith Zhao of StarFiveTech is still working on it to get it into upstreamable state.

This is very hard to avoid if you're not a huge manufacturer, as virtually all such small displays are made for portrait mode devices these days.

No.  The memory orientation of the display device is irrelevant nowadays.  This is standard systems integration work, and only requires the driver to expose the initial orientation as a module parameter.  Even the fbtft driver in staging supports rotate firmware parameter.  If you cannot stuff it in the graphics firmware (because it varies at run time), then push a couple of lines' patch upstream to expose it also as a module_param(), so it can be set by uboot etc. on the kernel command line overriding the one in the firmware.