piface
Posts: 4
Joined: Tue Mar 27, 2012 3:03 pm

Re: SD and other firmware,

Tue Mar 27, 2012 3:23 pm

Hi,

I have done some work on ARM and have built everything for a bare bonez linux form source. With the exception of wifi dongle firmware, all is open source.

I don't like closed source binaries that I can't see or modify.

I'm thinking specifically of SD boot device. I know work was well advanced a year or two back on integrating on open source driver into the main line kernel.

I've seen comments about GPU code.

What propitiatory binaries are required for out-of-the-box raspberrypi to run?

Thanks for any specifics.

mole125
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: SD and other firmware,

Tue Mar 27, 2012 3:39 pm

For full details search the forum for 'blob' there are lots of posts on the subject https://www.google.com/search?pseudoq=b ... gle+search

The GPU has firmware on which runs the GPU and also provides the initial boot up sequence. It is no different to the firmware on your PC motherboard which boots the computer and also runs the on board graphics chip.

The GPU is a highly specialized processor with something like 5000 registers, many different processing units which are incredibly complex and specialized and have had millions of hours worth of development on.

Even if broadcom were to release the source code for the boot loader and gpu it is likely to consist of poking random looking values into random looking memory addresses and be incomprehensible without extensive documentation on the processor even if it is well commented it is likely to be very hard to actually make it do anything different, even if the right compilers were available.  And that is just the simple bit, to actually use the GPU functionality without documentation would be pretty much impossible.

Is it just a philosophical desire to have access to all the code or are there any particular changes that you are actually wanting to make? There is no PC that gets you that open source.

User avatar
abishur
Posts: 4477
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
Contact: Website

Re: SD and other firmware,

Tue Mar 27, 2012 3:56 pm

Actually, it's 18K registers, not 5K, but the rest that Mole had to say was correct, the closed source sections of code will no more interrupt your usage of the R-pi than not messing with your motherboard's bootstrap or the firmware for your graphics card.  There method for interacting with the blob is to write code that takes advantage of existing libraries that have the ability to interact with the GPU.  Which, as I understand it, it standard procedure nowadays.
Dear forum: Play nice ;-)

mole125
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: SD and other firmware,

Tue Mar 27, 2012 6:58 pm

I knew it was a big number, just didn't have time to search the forums for where it had been posted before. Not sure if being a factor of 3+ out is close or not

pepedog
Posts: 1043
Joined: Fri Oct 07, 2011 9:55 am

Re: SD and other firmware,

Tue Mar 27, 2012 7:56 pm

Op,
All firmware is here
https://github.com/raspberrypi/firmware
Including a compiled kernel, modules, and libs + headers, plus of course the blobs

User avatar
jojopi
Posts: 3354
Joined: Tue Oct 11, 2011 8:38 pm

Re: SD and other firmware,

Tue Mar 27, 2012 8:22 pm

It really should be acknowledged that some of that is not firmware.  libGLES for instance.  So if someone wants to avoid proprietary software to a great extent they should be told to avoid the Raspberry Pi, not that it is no different from a PC.

mrrhq
Posts: 3
Joined: Tue Feb 28, 2012 6:51 am

Re: SD and other firmware,

Wed Mar 28, 2012 7:30 am

I think an effort should be made to avoid proprietary firmware modules.

For example I use Atheros (ath9k) Wi-Fi cards in my PC computers. They work great out of the box with GNU/Linux/UNIX and with Wicd and NM. Atheros also releases their firmware under the ISC, which is great–it makes sense. And finally, they are really cheap for Wireless 802.11 N cards.

Excuses like assembly code is "unreadable" and "can't be documented" is bullcrap.

But really, I am not saying that RP Project should reinvent the wheel and make their own Wi-Fi module, just demand them to make better choices to choose a "Linux-friendly" Wi-Fi adapter, so freedom users don"t have to use a Dongle or SDIO, or have to opt-in for Ethernet.

I think now I have reconsidered buying one until it is advertised as free hardware too.

mole125 said:


The GPU has firmware on which runs the GPU and also provides the initial boot up sequence. It is no different to the firmware on your PC motherboard which boots the computer and also runs the on board graphics chip.

Wait… No. Are you confusing a BIOS chip with a GPU chip?

Even if broadcom were to release the source code for the boot loader and gpu it is likely to consist of poking random looking values into random looking memory addresses and be incomprehensible without extensive documentation on the processor even if it is well commented it is likely to be very hard to actually make it do anything different, even if the right compilers were available.  And that is just the simple bit, to actually use the GPU functionality without documentation would be pretty much impossible.

Well, they" could just release the documentation along with it. I"'m sure anyone enthralled enough, who wanted to make changes, would look it up.

There are usually more efficient algorithms to manage anything from registery entries to color correction. And, since the source code is released, it can be trusted. It would soon no longer be Malware and do anything apart from what it"s supposed to do.

Is it just a philosophical desire to have access to all the code or are there any particular changes that you are actually wanting to make? There is no PC that gets you that open source.

It may just be both for most freedom users. And I have a Ben NanoNote, and RMS has a Lemote Yeeloong. And most PC motherboards that can be installed with CoreBoot and have no proprietary firmware modules are completely free too. So I have falsified your final statement.



tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: SD and other firmware,

Wed Mar 28, 2012 7:49 am

Mr. R said:


Excuses like assembly code is "unreadable" and "can't be documented" is bullcrap.


Having assembly code for the GPU binary won't help you in the slightest, as it's in an assembly language that's, AIUI, *only* used in the videocore processors, undocumented outside of Broadcom, and for which you have no tools.

Broadcom aren't going to give out documentation for that assembly language, nor are they going to give out the tools to manipulate it.  It really is that simple.

Mr. R said:


mole125 said:


The GPU has firmware on which runs the GPU and also provides the initial boot up sequence. It is no different to the firmware on your PC motherboard which boots the computer and also runs the on board graphics chip.


Wait… No. Are you confusing a BIOS chip with a GPU chip?


No, he's not.  The GPU acts as BIOS and booter for the ARM processor embedded in the SoC. If you'd done your homework, you'd understand this.

Mr. R said:


It would soon no longer be Malware and do anything apart from what it"s supposed to do.


Malware?  Are you completely mental?

Mr. R said:


And most PC motherboards that can be installed with CoreBoot and have no proprietary firmware modules are completely free too. So I have falsified your final statement.


"Falsified" my (_!_).

Do you have the source to the firmware that's running on your graphics card?  Your USB controller?  Your NIC?  Do you have the documentation and tools to manipulate those firmwares and more efficiently optimise the "register entries"?

No.  thought not.

Simon

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27442
Joined: Sat Jul 30, 2011 7:41 pm

Re: SD and other firmware,

Wed Mar 28, 2012 8:12 am

Mr. R said:


I think an effort should be made to avoid proprietary firmware modules.

For example I use Atheros (ath9k) Wi-Fi cards in my PC computers. They work great out of the box with GNU/Linux/UNIX and with Wicd and NM. Atheros also releases their firmware under the ISC, which is great–it makes sense. And finally, they are really cheap for Wireless 802.11 N cards.

Excuses like assembly code is "unreadable" and "can't be documented" is bullcrap.

But really, I am not saying that RP Project should reinvent the wheel and make their own Wi-Fi module, just demand them to make better choices to choose a "Linux-friendly" Wi-Fi adapter, so freedom users don"t have to use a Dongle or SDIO, or have to opt-in for Ethernet.

I think now I have reconsidered buying one until it is advertised as free hardware too.







Since the choice of Wifi adapter (USB) is entirely up to the user, not sure what that has to do with the Raspi itself. It's pretty easy to download firmware for all the adapters I've tried (sudo apt-get install firmware-realtek for example). Free as in beer though. You don't have access to the course code, which I don't care about anyway.

One built in to the board (if that ever occurs) will probably be from the same manufacturer as the SoC, Broadcom. Or maybe any future SoC will have wireless built in anyway.

Not sure any one has said assembly code is unreadable, or cannot be documented. That certainly not the case - it is readable, and it is documented. It's just that the documents on the GPU part of the SoC are not available to the general public. And as Simon said, it's a custom vector assembler, so for anyone outside Broadcom, fairly unreadable anyway. Actually, having thought about it, some of the code on some of the more esoteric cores in the GPU is in fact unreadable - at least, I cannot make head nor tail of it!

When it comes down to it, cost of the board trumps avoidance of proprietary software.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

mole125
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: SD and other firmware,

Wed Mar 28, 2012 9:12 am

Broadcom's internal documentation must be far better than our companies internal documentation then!

Generally I find ours is scattered over many documents in different places, and is generally one or more of the following: incomplete, incomprehensible, incorrect, out of date or missing relevant detail to make it actually usable (eg really detailed specs of what each api instruction means, but no details of how to actually use them together correctly).

Getting documentation into a state fit for public viewing is a massive and expensive task, making it actually useful and usable is an even bigger task, and making sure it doesn't have inaccuracies or detail missing larger still.

This is ignoring legal and business implications of releasing business sensitive details which may be in the process of being patented or provide a competitive advantage. Broadcom employees my be able to produce some open source public documentaiton if they had the will, but I much rather they spent that time on useful documentation for end users - eg how to get the best out of the public open interfaces into the hardware.

arturo777
Posts: 28
Joined: Sat Mar 24, 2012 10:02 am

Re: SD and other firmware,

Wed Mar 28, 2012 9:31 am

I very much agree with what Simon and James have said! Broadcom produce firmware because that's what they do best

I'm just hoping that some information is released about how to interact directly with the blob / firmware to allow non-linux (e.g. veeery experimental) OSs to run well on the Pi. I can understand that some GPU functions e.g. 3D, although nice, might be a little too advanced, but decent framebuffer, SD card access etc. would be very nice to have. I'm sure that 18 MB, even if closed sourced or difficult to understand, can do an awful lot and provides some cool interfaces.

The fantastic thing about the device is that it's really fully-featured (for its money) and pretty much un-brickable - perfect for tinkering

Return to “General discussion”