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

[brucehoult]

Good to know. I do bare metal stuff (including setting up PMP, page tables, switching modes etc) and I do compilers/JITs/emulators in user-land, but Linux boot and kernel stuff is somewhere I don't venture.

[DiTBho]

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

nice to learn 

with "fbcon" I meant a userprogram I wrote myself (kernel v2.6.39 era, many years ago), but it's userspace stuff that access /dev/fb0 to manage a tty terminal with simple features, and only one 8x16 font-set.
Everything is software-driven, even the vertical scroll.

Pros: it works everywhere (even on NetBSD, OpenBSD, and XINU) there is a /dev/fb0
Cons: slow

[DiTBho]

Ordered two devices for my friends (their money on my credit-card)

395.00 €, PINETAB2-10.1-inc 8GB/128GB ARM based tablet with detachable backlit keyboard      
395.00 €, PINEBOOK-14-inc  Pro ARM based laptop
000.00 €, Shipping   
----------------------------------------------------------------------
790.00 €, total

I'll move forward with the teres-1. Maybe I'll buy a RISC-V device in the second semester.

[DiTBho]

one thing I do find annoying is when a product that is supposed to be for developers has the "unique feature" to multiplex audio port between audio headphone output and serial console debug.

you need a program in userspace to move a bloody GPIO in early-boot.

Code: [Select]

#!/bin/bash
UENV_PATH="/boot/uEnv.txt"

case $1 in

        on) sed -i.bak '/debug=/c\debug=on' $UENV_PATH
            echo "Debug on headphone port enabled. Please reboot !"
            ;;
       off) sed -i.bak '/debug=/c\debug=off' $UENV_PATH
            echo "Debug on headphone port disabled. Please reboot !"
            ;;
        *)
        echo "Unknown option! Usage: debug_switch on|off "
        esac
Why hasn't u-boot been modified to provide this service?
Why open source is always missing essential things (like a debugging console) and you always end up angry with tons of hacks?!?

How am I going to manage this?
- open the laptop
- remove the motherboard
- find the GPIO
- unsolder the contact
- wire an hardware patch (pullup/down I have to check) to make the serial perpetually enabled

[Nominal Animal]

Linux boot and kernel stuff is somewhere I don't venture.

Righty-o; I tend to spend more time there than I do on bare metal (except for microcontrollers) myself. 

Why hasn't u-boot been modified to provide this service?
Why open source is always missing essential things (like a debugging console) and you always end up angry with tons of hacks?!?

Because systems integration is ignored, done by whoever has the time or interest with minimum time and effort spent.

I'm very serious about that.  It's the kind of field where you need a generalist to get it done right, with enough experience to know the various ways how it can be done right.  By the time you have that kind of expertise and experience, you're way out of the pay range anyone is willing to pay to get it done right.  (Granted, the maximum pay range for this is somewhere between highschool dropout and McDonalds worker, but "free" being preferred.)

It is exactly why I keep telling anyone messing with Linux to consider looking at LinuxFromScratch and writing their own example init systems, as that gives a vast majority of the experience needed.  Add a bit of kernel hacking and patch submission, and you're basically there, in my opinion.

How am I going to manage this?

Since it uses u-boot, I would use the gpio command instead.  If not supported on this hardware yet, then I would look into a patch implementing it, and pushing it upstream.

This, too, is something that should have been done by the systems integrator who put the example/default images together, being low-lying fruit and all.
Unfortunately, minimizing time to market no matter how un-integrated or incomplete the device is, is the primary goal nowadays.

[DiTBho]

Since it uses u-boot, I would use the gpio command instead.  If not supported on this hardware yet, then I would look into a patch implementing it, and pushing it upstream.

yup, doesn't seem implemented yet (2024 Git).
U-boot has a lot of bugs here and there and I have to fix them with higher priority.

This, too, is something that should have been done by the systems integrator who put the example/default images together, being low-lying fruit and all.
Unfortunately, minimizing time to market no matter how un-integrated or incomplete the device is, is the primary goal nowadays.

bah, the Teres-1 is a product made in 2018, six years ago, still for sale for ~250-300 euro shipped with all the tools you need, which is not "cheap", especially compared to alternatives.

You have to ignore that
- the SD card release mechanism is so clunky and poorly designed that it often gets stuck and you need a screwdriver to insert or remove the SD card
(risking splitting it, scratching the shell, or doing other damages)
- the eMMC is very slow. It's a known issue, and there are plans to replace it with faster units, but they are in perpetual limbo
- there are no other USB ports, you only have *one* on the left side of the laptop.
- the SoC's network NIC is shared in a mutually exclusive way with the LCD, so either you have the LCD, or do you have the network NIC
- the serial port is shared with the sound card without having put a physical switch on the mobo.

At least take care of the basic things... instead... it's semi-abandoned, kept going by very few volunteers

And look what you find pre-installed

Code: [Select]

# uname -r
3.10.104

kernel v3 

here is why I ***HATE*** everything made by Allwinner: because they release kernels in a partial way, they don't fully respect licenses, and what they release doesn't follow the standard lines, so then it takes years to take the things they do, to clean and to fix them, and bring them mainstream.

Code: [Select]

void export_gpio
(
  int gpio
)
{
  int fd;
  char buf[255];

  fd = open("/sys/class/gpio/export", O_WRONLY);
  sprintf(buf, "%d", gpio);
  write(fd, buf, strlen(buf));
  close(fd);

  sprintf(buf, "/sys/class/gpio/gpio%d/direction", gpio);
  fd = open(buf, O_WRONLY);
  write(fd, "out", 3);
  close(fd);
}
The provided tool to "enable the debug port" is ok for kernel v3, but it's deprecated stuff since kernel v5, so this stuff won't even work


I will try to fix u-boot, but not now. Now I need the serial console, and it has to work without having to depend on other matters.

[Nominal Animal]

This, too, is something that should have been done by the systems integrator who put the example/default images together, being low-lying fruit and all.
Unfortunately, minimizing time to market no matter how un-integrated or incomplete the device is, is the primary goal nowadays.

bah, the Teres-1 is a product made in 2018, six years ago, still for sale for ~250-300 euro shipped with all the tools you need, which is not "cheap", especially compared to alternatives.

Like I said, systems integration is just not something that vendors (including Olimex) or users care about.  It is like proper security: if it is not done from the get go, it will never be implemented, because you cannot just "add on" that stuff afterwards.

Physical limitations and bugs are a separate thing.

At least take care of the basic things... instead...

Don't you go there too: systems integration is just as important as choosing proper hardware for the task!
There is no "basic things first" in this type of hardware; it is either all of it at acceptable quality (including systems integration), or it is crappy.

(My criterion is: A tool that makes you frustrated every time you use it is a crappy tool.)

That said, I keep away from Allwinner hardware exactly because it is crappy.  It works for those who are satisfied with the Raspberry Pi class hardware (including dropping USB packets without notifying anything, breaking just about all protocols, because doing it correctly is too hard; instead, they just make it rare enough in software).  Suitable for hacks and one-offs, but not for an everyday tool.

I believe it is very informative to check linux-kernel and devicetree lists if support has been submitted to upstream kernels and if it has, by whom.  You'll find which SoC vendors do development and maintenance work with/for board manufacturers, which SoC developers push support into kernels concurrently or prior to boards relying on said support becoming available, and so on.  The discussions and reactions to the patches are more important than the code submitted, because those who are just doing their job and don't actually care, just dump the code and vanish.  (Or demand and whine that the code must be accepted upstream as-is, and other people will take the reigns over for maintaining it and bringing it up to spec.)

That way you also find interesting details, like how closely BeagleV Ahead matches the LicheePi 4A, so for any LicheePi U-Boot issues, the BeagleV-Ahead U-Boot Github tree ought to be very interesting.

[DiTBho]

(the dts is another problem to solve, because there are missing parts and wrong parameters

Umm. Sooner or later I will fix everything, I am not willing to give-up!

Just ... just found that even the power connector needs a reworking after 1000 cycles

Fsk#_#&*@#$ crappy hw!)

[DiTBho]

Don't you go there too: systems integration is just as important as choosing proper hardware for the task!
There is no "basic things first" in this type of hardware; it is either all of it at acceptable quality (including systems integration), or it is crappy.

umm, I don't entirely agree.

That way of thinking is for a product that could very well be an Apple Book Air. In that case, a company like Apple has all the internal and external resources to curate a "laptop" product that arrives "ready" for the end user.

In the case of Olimex the "product" is a "kit", which arrives in the form of a box of components to assemble, therefore it's not even the "kit" of a "finished laptop" but rather of a "laptop in development", that is, a "development board inserted into the shell of a laptop computer".

In 2018 they promised several interchangeable motherboards, that is, the possibility of choosing what to install inside the laptop chassis. However, in reality there is only one choice: that's is Allwinner A64 SoC! So, it wasn't my choice to use an Allwinner SoC in the teres1.

I would have preferred to avoid it, because I worked with Neo SBCs, which are based on their 32-bit ARM SoC. The Teres-1 uses a 64-bit ARM SoC, supposed to be better, and in practice at least the OpenRISC MPU doesn't have any of the hw-buggs found in the Neo' SoC,  anyway I found it in use with the Olimex's laptop, I had no choice here (except buy/not to buy), and when you participate "in the third row" - that is, as a spectator sitting outside the company - in the development of a product (because so it's advertized), well... what you expect is to have purchased a development board as a "product", rather than an object to "hack".

Anyway, as "develoment platform" sold as "product", there are basic things first. One of them is to provide a serial console without the need of hacking anything!

This is what pissed me off yesterday: that no one has bothered to fix the matter yet, and this wastes a lot of time, to the point of discouraging potential people willing to lend a hand and help.

-

For the next gen, the Teres-v2, I advised against using an Allwinner SoC again. here you will find the reasons in favor of one of the designers of the next version.

I hope they don't 

[Nominal Animal]

In the case of Olimex the "product" is a "kit", which arrives in the form of a box of components to assemble, therefore it's not even the "kit" of a "finished laptop" but rather of a "laptop in development", that is, a "development board inserted into the shell of a laptop computer".

Doesn't matter.  If systems integration is not done from the get go, it will never get done.  It is like security, which has to be baked in to the design, and cannot be effectively added on top later.  By hoping that "do the basic stuff first", you are effectively saying I'll accept this level of annoyance from my tools.

To me, tools that annoy me are not worth using.  It is that simple.

In 2018 they promised several interchangeable motherboards, that is, the possibility of choosing what to install inside the laptop chassis. However, in reality there is only one choice: that's is Allwinner A64 SoC! So, it wasn't my choice to use an Allwinner SoC in the teres1.

But it was your choice to buy one anyway.  I've looked at Teres, too, and chose not to buy it exactly because of the level of annoyance I knew would ensue from Allwinner SoCs, no matter how good work Olimex otherwise does.

For reference, see linux-sunxi project GPL violations, A64, and Linux mainlining effort pages.

The best way to describe Allwinner is not "evil" or "coldly calculating"; it is "inept".

Anyway, as "develoment platform" sold as "product", there are basic things first. One of them is to provide a serial console without the need of hacking anything!

Is it?  Someone else might say the basic thing first is to have the hardware (including display) boot a linux kernel properly.  Kernel hackers say the basic thing is to get the thing to boot into first-stage bootloader with memory and buses in a stable state.  Bootloader hackers say getting memory and buses to a stable state is the basic thing, with the rest to be developed "by the community".

See?  There is no "basic things first".  You can always define one that suits your context, but you cannot expect anyone else, especially a vendor like Olimex to agree to your exact definition, so it is meaningless.  It is exactly analogous to how "best" always depends on the context, and is basically useless as a qualifier or specifier.  To vendors, "basic things first" is always the minimum that is needed to get people to buy the product.  By your act of buying it, you have accepted the definition from Olimex as to what is sufficient –– assuming we agree you weren't deceived by the description and documentation, only frustrated by the lack of progress in the last five years or more.

Some time ago, I bought Ox64 from Pine64, the maker of PineTab and PineNote tablets and PineBook and PineBook Pro laptops.  Ox64 is a Bouffalo Labs BL808 SBC in microcontroller form factor, and is specifically marketed as a development platform for actual devices, similarly how Teres is specifically marketed as a "DIY laptop" (with a pretty prominent "Intended for use for ENGINEERING DEVELOPMENT, DEMONSTRATION OR EVALUATION PURPOSES ONLY and is not considered by OLIMEX Ltd to be finished end-product fit for general consumer use" note).
I would never recommend Ox64 for anyone wanting a Linux SBC for anything except than developing their own SBC variant based on BL808 (possibly for a specific purpose having strict size constraints), or to be used as a microcontroller/RTOS devkit, or perhaps as a test platform to learn to do systems integration on.  It is very much the SBC analog of the Teres-1 laptop.

This is what pissed me off yesterday: that no one has bothered to fix the matter yet, and this wastes a lot of time, to the point of discouraging potential people willing to lend a hand and help.

I bet quite a few of those who have bought a Teres have fixed it, but haven't bothered to push the changes upstream, keeping them in their own local repositories because it suffices for their "basic needs".  You know, "basic things first".  To them, pushing the fixes upstream is something to be done at a later time when they have the spare time and sufficient inclination, because it does not belong to their "basic things first" definition.

What you are railing against, is that others do not have the same priorities as you do, and this is hindering your progress.  Unless you try hard to push your changes upstream, you really don't have a leg to stand on in requiring others to push their changes upstream either.

Aside from a couple of really-cheap SBCs I bought more for the price than anything, I do not use Allwinner SoCs.  I like Rockchip, Samsung, and TI SoCs because the designer/vendor themselves push the support into the core packages; and Amlogic because of Linux-Meson (not affiliated with Amlogic) and BayLibre (doing a good job adding more mainline support).  Rockchip in particular is making a real difference in the Linux kernel support of their designs.  (I haven't checked U-Boot support state, though.)

I'm giving you hard pushback here, because this will happen again and again: it is a human social issue, and not a technical one.  It will not change, because there is nothing to drive such a change; people will do what they do, and not contribute, because they think someone else will do it anyway so it would be waste of effort for themselves to do so.  The only thing we can do to change it, is change our own behaviour first, and then by example show exactly why behaving this way saves time/money/effort and is therefore the more effective/efficient way to do things –– and obviously to spend money only on products whose manufacturers and vendors are doing the right thing.  Anything else is just complaining about humans being humans (which I admit, is cathartic, but otherwise not useful unless a better behaviour pattern that benefits themselves too, and not just ourselves, is well known; but even then, we have to do it first ourselves).  I cannot expect "better" support from Pine64 or Olimex than what I can already see before I buy anything, because doing so is unreasonable.  For better support, I can only either join or start a new community showing how pooling our efforts will benefit everyone in the community.  And, if I do not intend any long-term commitment, how could I expect that from anyone else?  Even the vendor has already been paid.  It would be unrealistic.

[DiTBho]

about "social issues" ... next stop will likely be people on { Youtube, TikTok, ... } telling not only retro computing enthusiasts but also open hardware laptops enthusiasts are all "masochist" 

( Jeff ... did it )

[Nominal Animal]

about "social issues" ... next stop will likely be people on { Youtube, TikTok, ... } telling not only retro computing enthusiasts but also open hardware laptops enthusiasts are all "masochist" 

( Jeff ... did it )

They say the same thing about people who only use hand tools for woodworking, drive single-gear bicycles, enjoy jigsaw puzzles, and so on.  When they don't personally see or feel the immediate reward, it is easier to resort to irrational beliefs than actually think it through.  Just consider how large a fraction of archaeological objects are classified as "religious artefacts", just because nobody has bothered to think or examine if they have a practical purpose.  It is the easiest way to avoid thinking it through, that's all.

I was thinking more about how difficult it is for us humans to see the bigger picture and to choose the behavioural patterns that maximizes reward over time, compared to ones that bring minimal but immediate rewards.  (In psychology, this is called delayed gratification, and is difficult to develop in the world of gamified social media where tiny immediate rewards are all that matter.)

The main reason I push back so hard and try to explain/push these things is that this (with respect to Linux, at least) is a rare case where even a single individual can make a big difference.  Everyone knows about Linus, but my favourite example is Greg Kroah-Hartman, who still helps out-of-tree developers (especially commercial vendors) upstream the support for their devices.  Plus all the stable and linux-cve-announce stuff he does.

In the embedded world, it means that a single voice pointing out how using Allwinner SoCs gives you lower initial cost but huge maintenance/development debt, compared to Intel/AMD/Rockchip/Samsung/Texas Instruments/Amlogic et cetera that may have higher initial cost but much less debt (systems integration must be considered such a debt, although volunteers can help if you can offer the beta devices at lower prices), can help others realize this, leading to companies shifting their cost calculations from initial to lifetime (at least a little bit! I'm not that much of an optimist), and that should lead to future Linux-compatible hardware becoming cheaper to maintain and develop.

I hope you and others see my logic here, and my positive/supportive intent at the root of my pushback/ranting. 

[DiTBho]

this is the other Jeff. His video is... hilarious since he's collecting old Macs 

[DiTBho]

I hope you and others see my logic here, and my positive/supportive intent at the root of my pushback/ranting. 

You are always welcome 

I would love to have your convincing argumentative skills.
I simply suggested avoiding Allwinner for Teres-v2, mentioning the terrible experience I had with their 32-bit SoCs on Neo SBCs.
This is what the community lead developer of Teres-2 replied (in public):

The A64 and possibly A20/A33 are the only chips that i am using from allwinner and i consider the others an unusable garbage tbh

The A64 because it doesn't have a known vulnerability to CPU bugs e.g. spectre, meltdown, etc.. and because it's cheap and documented chip that runs libre software stack (arm trusted firmware, crust, uboot) with an exception of the FEL protocol that is proprietary, but is easily auditable and it doesn't seem to be an issue of willingness to open-source rather that open-sourcing such a thing is kinda difficult to do in a usable way as it's an integrated thing in the chip that you can't really easily change and is there as a last resort to prevent hard brick situations..

So the idea of using it for development is that there won't be any surprices that will take time out of hardware development, if i mess up traces somewhere then the chip costs ~2 EUR to replace and so it's kinda really good solution for hardware development as it provides a robust foundation to use from which we can then implement additional modules and have a transition on riscv, bcs currently i am not aware of a single riscv64 chip that is not major pita or doesn't have major issues to be used.. the TH1520 is like the least broken imho and seems to get a decent mainline, but has issues with riscv implementation https://github.com/revyos/revyos/issues/17#issuecomment-1867110963 and the NPU/GPU is currently proprietary and it's not clear if it will get open-sourced and from me trying to implement compatibility for the TH1520 in armbian it's a constant show of surprices that would take the time off of hardware development.

Another problem came up while reading some pdf: the at the moment the Teres-v1 rev 1.5 (motherboard revC) has 2GB of soldered RAM, if you want to increase it... well, the Allwinner A64 SoC doesn't address more than 3GB... that's another hw problem and/or a strong argument to convince them to avoid A64 for the next generation

[SiliconWizard]

this is the other Jeff. His video is... hilarious since he's collecting old Macs 

Yeah, nice clickbaity title. I don't even blame, that's just the game.

[brucehoult]

this is the other Jeff. His video is... hilarious since he's collecting old Macs 

Ahh .. young Yearling. Is that his dad?

(I'm led to believe his name is András István Arató ... but there is a resemblance! And the guy is an EE IRL)

[DiTBho]

Ahh .. young Yearling. Is that his dad?

I haven't watched enough of his video to know these details.

[DiTBho]

this is the other Jeff. His video is... hilarious since he's collecting old Macs 

Yeah, nice clickbaity title. I don't even blame, that's just the game.

Yup, part of the Youtube game.

Even when he installs ram-sticks which are NOT supported, and then complains that the mac doesn't work.
Or when he says he wants to relive the emotion of the Mac of the time (2002), and then he installs SSD.
RoFTL

Oh, but how I would like a Sonnet Tempo s/ATA PCI64/PCI-X HBA ... 

(and a s/ATA port inside the teres1 ... )

[langwadt]

In the case of Olimex the "product" is a "kit", which arrives in the form of a box of components to assemble, therefore it's not even the "kit" of a "finished laptop" but rather of a "laptop in development", that is, a "development board inserted into the shell of a laptop computer".

does making it a "kit" avoid the paperwork of getting approvals?

[SiliconWizard]

I'm not too much into vintage computing myself (I mean, in an active manner), but the last related thing I did a couple years ago was to revive a Sinclair QL, a modest, yet much rarer beast than any Macintosh.

[brucehoult]

I'm not too much into vintage computing myself (I mean, in an active manner), but the last related thing I did a couple years ago was to revive a Sinclair QL, a modest, yet much rarer beast than any Macintosh.

Ahh, an 8 bit computer :-) :-)

[SiliconWizard]

I'm not too much into vintage computing myself (I mean, in an active manner), but the last related thing I did a couple years ago was to revive a Sinclair QL, a modest, yet much rarer beast than any Macintosh.

Ahh, an 8 bit computer :-) :-)

Sort of... not.

[DiTBho]

does making it a "kit" avoid the paperwork of getting approvals?

90% so it seems 

[DiTBho]

I spent something like 2K euro for PPC stuff, not only Apple but including 600 euro for a modded MDD/G4.
I would say, because I appreciate architecture and I like not only studying but also working on it in my spare time.

someone understood me, and liked my comment 

[DiTBho]

kreyren on 29 March 20, 2024

DiTBho on March 20, 2024
Just checked, the pinetab2 uses the Rockchip RK3566 SoC

Afaik the reason why OLIMEX didn't provide the RK3399 and RK3566 is that they were very unreliable software-wise (afaik they release the chip and then rely on the community to mainline them while not providing sufficient amount of documentation?) and tsvetan not wanting to support that as the resulting mainline is often very problematic and takes long time to get implemented in a way that is acceptable in industrial settings (OLIMEX's main focus)

For me in terms of arm architecture only use Cortex A7/53/55 and consider everything else garbage due to the CPU vulnerabilities, but i plan on supporting all chips as long as the required docs to make boards for these are available or unless someone wants to do the adventure of reverse-engineering them and contributing that (that's what the SOM management is meant to be for)

This is one of the public responses, which explain the reasons for the choices made.
I'm a bit perplexed, because it seems like it's always the same problem regarding software development, documentation, etc