| |||||||||||||
Free Circuits FoundationFree Circuits FoundationPosted Jul 26, 2012 20:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)In reply to: Free Circuits Foundation by jebba Parent article: GNU Linux-libre 3.5-gnu: Free and a half
>Do you really think the FSF's four freedoms require the design code to the CPU?
And why do they require design of network card's microcode? What's the difference?
>The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
>Which processor they run on is irrelevant from the perspective of the FSF.
(Log in to post comments)
Free Circuits Foundation Posted Jul 26, 2012 21:44 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
>>Do you really think the FSF's four freedoms require the design code to the CPU?
>And why do they require design of network card's microcode? What's the difference?
Microcode/firmware is a software application with source code. The design files are to manufacture hardware, they aren't applications. I presume you know this though.
>>The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
We're talking about the Free Software Foundation, not the Free Hardware Foundation.
>>Which processor they run on is irrelevant from the perspective of the FSF.
Meh, I've been bitten by a troll.
Free Circuits Foundation Posted Jul 26, 2012 21:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Microcode/firmware is a software application with source code.
Nope. Microcode is an essential part of the hardware.
>The design files are to manufacture hardware, they aren't applications.
> We're talking about the Free Software Foundation, not the Free Hardware Foundation.
> Meh, I've been bitten by a troll.
Free Circuits Foundation Posted Jul 27, 2012 2:45 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Microcode/firmware is a software application with source code. The design files are to manufacture hardware, they aren't applications. I presume you know this though. Are you familiar at all with FPGAs and CPLDs? I'll give you a hint: The "P" stands for "Programmable." Many of these require their bitstreams to be loaded at power-up before they perform their function. This bitsteam is loaded from some other device on the board, most often some form of serial EEPROM or flash. Often, the logic that's in these same FPGAs and CPLDs will get reduced to an ASIC if the volumes are high enough, but not always. The source code for the FPGA/CPLD is the same source code used to produce the ASIC, generally. Microcode is essentially a part of the design that's been moved from the fixed-in-transistor domain (much like an ASIC) to the programmable domain. The same source code (also likely in the same sort of HDL, although perhaps a custom HDL for the purpose) underlies both. Microcode compiled to a ROM instantiated in transistors is as much an "application with source code" as the very same microcode compiled to an image loaded into the patch-RAM next to the ROM it replaces. The bright line you suggest exists doesn't. Here's an example of a microcode ROM embedded in a voice-synthesis processor. It's 2K bytes, so it's reasonable to suggest it had source code associated with it. This ROM contains control sequences for making various sounds "baked in" to the chip. The chip is sold as a product that makes specific vocal sounds listed in the datasheet. If I replaced this ROM with a RAM and required you to load a bitstream to make this processor functional, are you suddenly less free? I'd argue that because you can now receive bug-fixes, I've only increased the value of this part to you. As a matter of fact, the specific device I took that clip from has a pin that disables the internal ROM and lets you fetch that same control data from external memory. Because that's technologically possible, are you saying free software should not use this chip? Or it should only use this chip with the original baked-in ROM?
Free Circuits Foundation Posted Jul 27, 2012 2:48 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Microcode is essentially a part of the design that's been moved from the fixed-in-transistor domain (much like an ASIC) to the programmable domain. The same source code (also likely in the same sort of HDL, although perhaps a custom HDL for the purpose) underlies both. I meant to say "Loadable microcode" above. My point is, what is so magically freeing about baking microcode into ROM vs. allowing it to be overridden by a copy in RAM? The manufacturer sells you a hardware device that only they have the capacity to modify. Just, in one case you have to buy an entirely new chip to get an update, and in the other, they can send you a field update. The line between hardware and software is often blurry, which is why terms like "firmware" exist.
|
|||||||||||||
