[Top][All Lists]

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

Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux

From: Bernd Paysan
Subject: Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux
Date: Sat, 16 Aug 2014 16:22:42 +0200
User-agent: KMail/4.11.5 (Linux/3.11.10-21-desktop; KDE/4.11.5; x86_64; ; )

Am Samstag, 16. August 2014, 13:28:22 schrieb Anton Ertl:
> On Sat, Aug 16, 2014 at 12:52:00AM +0200, Bernd Paysan wrote:
> > FSF's issue with OpenSuSE are the firmware blobs.  I'm not convinced of
> > that issue: This is just technical, the manufacturers of these chips use
> > RAMs to store the firmware so that they can develop that stuff without
> > many long turnarounds.
> That would also be possible with flash.  They probably do it because
> it saves them money, e.g., by using lower standards for the
> development, because bugs are cheaper to fix in the field.

Flash adds 10 masks to a process; this easily makes a chip too expensive.  The 
problem might go away with ReRAM, which needs just one mask adder, and the 
smaller ReRAM memory (compared to RAM) might cover that cost.

> In any case, that does not matter for the question of free software.
> This is not immutable hardware, this is plain software.

The hardware could be an FPGA, then it wouldn't be immutable.  It just would 
be more expensive as FPGA, so people don't do it in volume (actually, they are 
starting to do this, the PSoC4 I have just got, has a CPLD-like unit for its 
peripherals instead of having them hardcoded).  They do use RAM in volume, 
because it is cheaper than Flash.  The firmware blob for such chips usually 
doesn't change anymore after release, but re-masking the chip for ROMs is more 
expensive than the RAM overhead, so it doesn't get done.

>  All the
> arguments for freedom of software apply.  Indeed, the FSF started with
> something quite close to these things: with a proprietary printer
> driver.
> > Therefore, you upload the firmware by the OS.  This is state of
> > the art;
> So is other proprietary software.

From a copyright point of view, this is part of an integrated work, the chip 
you bought.  The chip and the firmware together perform the function, these 
chips are not general purpose computers, they have a special purpose.

> > If you use a system that is free in the FSF sense, you will have troubles
> > with many hardware components, except those already initialized by the
> > BIOS (which does the blob uploading for you then).
> Yes, so if you want to run a 100% free software system like gNewSense,
> you will have to select the hardware even more carefully than otherwise.

And you ignore all the parts which get their blob thru the BIOS, which makes 
the whole thing hypocrite for me.  Even your main processor doesn't really 
work without a firmware blob installed by the BIOS (the loadable microcode).

In other words: If you require all proprietary blobs to be removed, you get 
about nowhere on a modern computer.  I once looked at an iPhone teardown and 
went through all chips on that system, and the only one without a controller 
and loadable code was Dialog's power management.  That's the typical case 

The whole concept that hardware is immutable and software is mutable is no 
longer true - hardware is partially mutable these days, and careful choice 
doesn't work anymore, as this is almost everywhere.  You just can pretend to 
ignore some of the blobs, even though they are the most important ones (a 
considerable amount of the Intel ISA is loadable microcoded stuff, and the 
processor would probably much faster to call the Linux kernel or handle 
interrupts if you could change that code - and it *is* changeable).

Bernd Paysan
"If you want it done right, you have to do it yourself"

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

reply via email to

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