[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
today.
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"
http://bernd-paysan.de/
signature.asc
Description: This is a digitally signed message part.