[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libreplanet-discuss] EOMA68 and freedom in digital technology

From: Paul Kocialkowski
Subject: [libreplanet-discuss] EOMA68 and freedom in digital technology
Date: Sat, 10 Sep 2016 20:56:04 +0200


I'm digging this up because Christopher raised a few points I would like to
answer. Since it is no longer about the Parabola blog article, but rather about
EOMA68 and freedom in digital technology in general, I changed the subject.

Le jeudi 25 août 2016 à 14:24 -0400, Christopher Waid a écrit :
> On 2016-08-25 05:01 AM, Paul Kocialkowski wrote:
> > Le jeudi 25 août 2016 à 04:42 -0400, Christopher Waid a écrit :
> > > The laptops we sell currently @ ThinkPenguin are not RYF'd and 
> > > shouldn't
> > > be RYF'd, but we are working on something better than LibreBoot in 
> > > that
> > > it solves the free software problems in a more permanent long term 
> > > way:
> > > EOMA68. X86 is dead and we do not need LibreBoot for non-X86 systems.
> > 
> > I'm very surprised to read this. How do we not need Libreboot in 
> > general?
> > 
> > Having a fully free bootup software distribution is IMO crucial to pave 
> > the road
> > for free software support. Note that U-Boot includes proprietary 
> > software and
> > should not be included as-is in or recommended by any FSDG-compliant 
> > dsitros.
> > 
> > Also, Libreboot is currently based on Coreboot (which, by the way, 
> > supports an
> > increasing number of ARM devices, with Chromebooks) but there's not 
> > reason it
> > can't handle U-Boot in the future too, or whatever other free bootup 
> > software.
> > 
> > So with upcoming ARM Chromebooks, the very large number of ARM devices 
> > that can
> > boot up with free software and other interesting platforms such as 
> > POWER8 and
> > POWER9, Libreboot still has a bright future ahead.
> We already have completely free versions of Uboot for various ARM and 
> MIPS devices. All of our routers have shipped with the complete set of 
> source code for the OS and bootloader. The devices are RYF certified and 
> do not contain any proprietary bits in the version of Uboot run on our 
> routers.

Of course, but U-Boot is not a fully free software project and does not provide
binary releases anyway. I do agree that it is extremely easy to come up with a
fully free binary release of it for a number of boards.

> router-tpe-r1100
> I want to make it clear that I don't dislike LibreBoot and I'm not 
> saying it has no value. It's value right now to me is clear. It's 100% 
> free software for what is otherwise proprietary. I value that. As we 
> move away from X86 the value in it from a freedom-perspective will 
> diminish as alternatives exist. In that position I would begin to think 
> about alternative projects to work on if my primary focus was advancing 
> software freedom.

This is because you are, for some reason, associating Libreboot with x86. There
is no particular reason to do this, and I'm working to add support for ARM
devices in Libreboot. MIPS devices could also be integrated as well. OpenPOWER
support is also planned to get integrated in Libreboot.

> What I believe will make it valuable to people down the line will be 
> functionality (within the free software community and maybe even 
> beyond). I don't know what this functionality is right now and I simply 
> know that it's got value to some use case still. If I had to take an 
> educated guess I'd probably say it has functionality which is useful to 
> system administrators in server environments. From what I understand of 
> CoreBoot from which LibreBoot is derived that functionality was what has 
> in the past spurred CoreBoot's adoption by those outside the free 
> software world.

I'm not sure extra functionalities are a requirement, but having something that
works properly probably is. We are working hard to achieve that, on every aspect
of free software support at the lower levels. However, I truly hope that we
someday only have to care about adding new features, over getting the basics to

> If servers were a high priority for us (they aren't) I'd probably be 
> pushing/sponsoring LibreBoot. I was the first person to suggest 
> LibreBoot add a donation option. Right now our focus is on laptops, 
> desktops, and typical end-user hardware. I want to see GNU/Linux and 
> free software adopted by the masses. It's largely won in the server 
> arena and there is a huge market opportunity here for free software 
> servers to anyone who wished to pursue it.

Well, I don't like the idea to narrow our efforts to specific use cases or types
of users. Different people and entities have different needs. Some do need to
use servers. Frankly, I'd rather try and support every aspect of digital
technology out there rather than voluntarily restrict the scope of what should
be worked on.

And anyway, there isn't so much stuff we actually have the ability to free, so I
think this is what drives what we can actually do to the largest extent. Also,
given the best-effort nature of all this, I think people tend to work on what
they personally like/need, and I think this is fine.

This is, of course, assuming a community approach and already existing devices.
Your approach, which is about producing devices, is indeed quite different and
you probably need to target an audience there. But then again, I'm happy to see
that different companies are working on liberating different areas of digital
technology by producing devices for that purpose.

You pick what seems to make the most sense to you, others will pick something
else and if enough people do that, we may just cover a large part of the

> > > The reason this issue hasn't been solved by us is because it's simply
> > > not possible given Intel's hostility and refusal to cooperate. Reverse
> > > engineering is a non-trivial task and the resulting code would not run
> > > on modern Intel systems due to digital signatures.
> > 
> > Of course, we all agree that x86 is a dead-end, at least in the long 
> > run. There
> > are still possibilities with somewhat old Intel and AMD hardware, but 
> > these will
> > be outdated eventually. Also, note that most of these old x86 platforms 
> > are
> > much, much faster than the A20.
> Of course. The solution isn't intended to outperform. It's intended to 
> solve a problem. That problem is X86 doesn't work for us and it's too 
> costly to have to design and manufacture our own non-x86 hardware (which 
> is critical given all newer non-X86 hardware is dependent on other 
> proprietary components such as 802.11ac wifi chips).

My point is that not all x86 hardware is doomed. With some work, some AMD
platforms could work with fully free software. Thus, I'm not saying it's a
solution to the problem, I'm saying it gets rid of the problem, on those
specific devices.

But of course, since we're talking about old platforms, this approach is quite
limited in time. So it is likely that such computers will either become too
rare, obsolete in some aspects, or will simply be outperformed by newer
generations of computers that can run with fully free software as well.

>  The solution to 
> that is modularization. This has a side benefit of making it easy and 
> cheap (relatively speaking, and therefore feasible) to manufacture new 
> 'models' in addition to giving us inroads to obtain source code for 
> higher end CPUs [moving forward]. Even ones that aren't yet on the 
> market! That's a huge change to the two steps forward one step back we 
> were doing before. Right now we are several years behind because of our 
> dependence on X86 and companies who won't cooperate. By moving away and 
> modularizing we can let companies designing CPUs cater to our demands. 
> This is what you get from competition.

I agree modularization is nice, but I don't think it fundamentally changes the
game regarding freedom, but more of a practical, nice feature to have. For some
other aspects, like environment-related ones, it is of course quite fundamental

> > > We can do a lot more  than what is feasible with LibreBoot, but it has 
> > > taken
> > > years. Now that EOMA68 crowd funding campaign has succeeded though or 
> > > is about
> > > to succeed we can do a 100% free software system
> > 
> > Note that the level of free software support brought by the EOMA68 is 
> > not really
> > something new.
> This is incorrect or a misunderstanding of the value here. Its taken 
> years and a lot of reverse engineering to get the Allwinner A20 
> supported. While the first computer card is in part built off the work 
> of others at a component level it's not the value for which I'm 
> referring that EOMA68 adds in relation to free software. The value is in 
> the modular standard and what it is enabling us to do in the free 
> software world. To look at the CPU and components individually is to 
> misunderstand the value in this project. It was not essential that we 
> utilize the Allwinner A20. It just made a lot of sense given the work 
> others have already done including the work of Luke (for which we 
> sponsored). The value is we get to pick and choose each part that goes 
> into a system and when one company upstream doesn't cooperate we can 
> look elsewhere. We don't have to spend years reverse engineering parts 
> thereof when we can work in collaboration with the companies upstream 
> doing the design of these CPUs/SOCs. To achieve that we need control 
> over the design and manufacturing process. This is not something we had 
> before. This is not something most companies have. Most companies build 
> off of reference designs and the product designs are little different 
> than the reference designs in many if not most cases. A tweak or two at 
> best.

Again, I don't see why modularity changes the game here. The problem has never
really been the lack of acceptable hardware. ARM Chromebooks are such an
example. There have been countless other Allwinner boards, such as the ones from
Olimex, that do very well with free software. For each possible platform that is
somewhat interesting to free software, there are already boards available.

The way I see it, the EOMA68 is a i+1 iteration of this. Most certainly a much
better one than most of the ones before, but not a game changer still. Again,
just to be perfectly clear, this is not to undermine the project. All iterations
that are better than the previous ones are leaps forward, and that's the way to

> > There have been dozens of computers, some of which come with a
> > free board design, using platforms that are as good for freedom, 
> > especially with
> > Allwinner (but there are lots of others). The linux-sunxi community has 
> > been
> > working hard on those for years and years, so this is nothing new or 
> > specific to
> > the EOMA68.
> > 
> > Many ARM Chromebooks even go a step further, with a free software 
> > embedded
> > controller firmware.
> I'm in many cases referring to laptop designs. This isn't totally 
> correct though particularly as it relates to laptops. All of the ARM 
> Chromebooks have fundamental problems in one way or the other. There are 
> no free software friendly 802.11ac wifi chips and these wifi chips are 
> integrated on every single modern Chromebook that is readily available 
> [last I checked]. You can't easily replace these chips like you can with 
> X86.

This is correct, but is also a detail because it has never really been a
problem. Sticking-in an ath9k_htc dongle solves the issue with nearly zero
associated drawbacks (and we can thank you for that). 

>  To solve this problem and many others in the process is to gain 
> control over the overall design and what you can utilize as your 
> building blocks.

Of course, but anyone designing a board can do that. This is what was done with
EOMA68, that extra step was taken. Modularity is only a flexible, practically
convenient way to achieve that, but the problem has never been there.

>  With the laptop housing that is part of this crowd 
> funding campaign you'll be able to get an Allwinner dual-core A20 on the 
> Libre Tea Computer Card today and upgrade to a quad-core CPU tomorrow. 
> It won't cost $500 either. It'll be under $100.

To contrast, I personally fully support this approach (especially from the
environmental perspective). I'm just saying, it's not a game changer on the
freedom perspective.

> > > (that is LibreBoot doesn't magically make a computer 100% free, there 
> > > are
> > > other problematic components).
> > 
> > Of course, but nobody claimed that it does. It is only a very 
> > significant piece
> > in the software freedom puzzle.
> It's one of many pieces. It's not quite as significant as people think. 
> If it were gone it wouldn't really make any difference.

Note that by Libreboot, I mean "fully free bootup software" in general,
regardless of the boards that are currently supported. This is what Libreboot is
and targets, and it'll grow to cover as many of the boards it can support as

So what I meant is that fully free bootup software is a significant piece in the
software freedom puzzle. Perhaps the most crucial one.

> There are many components for which we are dependent and there are no 
> alternative options. Wifi firmwares are a great example. We have only 
> one driver and chip for modern 802.11n that we can utilize (AR9271) and 
> nothing for 802.11ac (in any format, PCIE/M.2/USB). It won't be the case 
> that we can get AR9271 adapters manufactured forever and at some point 
> it will become critical that we work on obtaining sources [another 
> project we're working on].

I fully agree. Technology moving so fast really doesn't help either. I'm truly
grateful that people like you are working hard to keep up the pace and make sure
free software remains relevant and freedom is still a possibility without living
ten years in the past.

> Wifi cards are fundamental to modern computers. You can still get away 
> without 3D acceleration, but good luck with a system that doesn't have 
> internet connectivity.

Agreed, without a doubt.

> There are zero good options for graphics right now too. Graphics are not 
> quite critical because we can ship without it for the moment and the 
> user experience is still "good enough",

Well, it would be unfair to say that the situation is that bad. Drivers such as
nouveau support cards (with free firmwares in many cases, by the way) that are
not tied to any specific architecture (not only x86 uses PCI) and there are
efforts to support GPUs embedded in ARM SoCs, such as Freedreno and Etnaviv (and
nouveau, too). I think this is all valuable and shows that we're going
somewhere. Maybe not as fast as we'd all like, but the amount of work is huge.

> LibreBoot is a duplication of effort as far as critical components are 
> concerned and we should try to avoid duplication of efforts given the 
> limited resources available.

This sounds particularly wrong to me. You're assuming a specific structure here,
very much company-like, where a group of people get to decide of the directions
for the group and others follow. This is not how our community works. Our
community is best-effort based, so different people (or different companies)
will work on different things as they please.

I find it quite strange to make claims that suggest we should all follow one
specific direction. People just do what they want to do. This is the mostly
natural things for way to work in our community, and I have no doubt that they
will keep working this way for a long time.

> > > We've got the source code for LCD/Keyboard controller firmware,
> > 
> > Regarding LCD: are you talking about a MIPI interface done in software 
> > with a
> > MCU? Please feel free to share details about this LCD controller 
> > firmware, I'd
> > be very interested to learn more about it, it sounds unusual!
> I know a little bit about it, but not enough to give you details. The 
> details are readily available though.

Okay, I'd be interested in those details out of curiosity, if you'd like to
point me to them (I can take no for an answer, this is asking you to do some
extra research work, that you can certainly do much more efficiently than me).

> > > bootloaders, CPU micro code
> > 
> > Huh? Again, please share details about the CPU microcodes. I am not 
> > aware of any
> > ARMv7 implementation using a microcode at all, nor of any that was 
> > liberated.
> Overgeneralized. As far as the A20 goes you are correct. I can confirm 
> that there is no micro code in this particular CPU.

That makes sense.

> I'll throw out some other words that may make more sense here:
> SPL uboot in mainline 2015-10- ddr3 timeings initialization and pll 
> clocks.

Yup, the community sure did a great work there. RAM init is always the trickiest
part of bootup and in that case, Allwinner only barely helped (or when they did,
most of it had already been figured out IIRC).

> > > and similar for the EOMA68 laptop housing and Libre Tea Computer Card. 
> > > That's
> > > huge. And there are more significant developments coming including the 
> > > release
> > > of schematics and higher end CPUs.
> > 
> > I fully agree that this is great and I support your project. However, 
> > keep in
> > mind that this is nothing new or groundbreaking (not to undermine the 
> > project
> > and the efforts associated with it).
> I disagree. There is simply nothing you can compare this project to. We 
> are achieving results that can't be demonstrated via any other means. If 
> we could get here some other way at a lower cost with the same long term 
> impact I would have gone that route.

See what Olimex has been doing for years then. They're also coming up with a
laptop design. I agree that you went steps further than most before, but this is
incremental improvement, not something truly new and groundbreaking compared to
what existed before.

> The issue is your looking at one thing. A few specs. It's not the specs 
> that matter. It's the standard, it's the modularization, it's the 
> response and cooperation we are getting already as a result of our 
> actions here, etc. Intel and AMD are not going to cooperate and building 
> off of other companies products (higher up the chain) is not a reliable 
> long term solution.

Again, I don't see how modularization changes anything here. Hardware
availability has never been the problem. For laptops, we only had minor
annoyances, like Wi-Fi chips that require proprietary firmwares, with the most
advanced designs for freedom like ARM Chromebooks. So you took a step forward
there. It's not a revolution, it's a step forward: solving the (minor) Wi-Fi
issue. For single-board computers, you didn't bring any specific improvement
over Olimex's Allwinner boards.

Again, I don't want to sound like your project doesn't matter to me, because it
really does. Only that it's an improved iteration over what exists rather than
whole new ground. And that's totally fine by the way, it is a very sane way to
go. It also shows that you're not the only person on earth caring about these
issues and producing hardware that solves an increasing number of them (even
though I suspect some other players produce devices with such results without
really aiming at that goal).

So overall, thanks for your work :)

Paul Kocialkowski, developer of low-level free software for embedded devices

Coding blog:
Git repositories:

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]