Heh, I used to hate them too. I had a onboard chipset that I called “Bracom” because it didn’t support *ANYTHING* under linux.

Don’t get overly optimistic. It sounds like Raspberry Pi will have drivers made of a huge closed source binary blob, which is basically the reason why you had those problems with the WiFi card. Expect similar problems if you want to use your own kernel.

God, I love the air of optimism you zealots project.

liz, Raspberry Pi is a great project and I’ll buy a board to tinker with once you start mass producing them. However, it looks like Broadcom will screw us over with closed source drivers and by not making the SoC documentation publicly available. I don’t really care that much about accelerated graphics and the video decoder. I’d be happy just to have Free Software which takes me from powering the board to the login prompt.

Please don’t call me a ‘zealot’, I think my concern is entirely legitimate. It’s not like this is a non-issue, Broadcom hasn’t done similar stuff in the past or there aren’t other ARM SoC which work perfectly fine with 100% FLOSS.

To be honest I’m getting a bit bored with all this rubbish. I’m not saying you are a zealot, just misinformed. Broadcom will not ‘screw us over’. You will have access to in excess of 90% of the features of the GPU through the provided drivers. The last few percent are pretty uninteresting the the vast majority of users. (some interfaces etc). There will be documentation for most stuff accessible from the Arm e.g. GPIO’s.

You will have free software that gets you to a Linux prompt, or desktop or whatever. No problem. If you have no need of the GPU (except for display out) or video encode, even better – you would be using very little non-OSS stuff.

There are *NO* other Arm SoC available at this performance and this price that are fully OSS. You information there is incorrect. I’d also like you to name an occurrence where Broadcom has done this in the past bearing in mind this is the first project of its kind.

If you need the SoC specs e.g. memory bandwidths, BGA pinouts etc, then you presumably have a project which needs an Arm+GPU which isnt a Raspi, so therefore you would need to approach Broadcom themselves.That’s nothing to do with the foundation.

Finally, this IS a non-issue for the use to which the Raspi is intended, that of helping teach children programming.

JamesH, That’s not what I was saying. Of course that USB devices will work as long as the kernel you’re using includes drivers for them. My concern is about the closed source drivers used for on-board peripherals, plus the lack of an SoC technical reference manual.

More exactly, if you’ll want to use a newer kernel it’s likely that those drivers won’t work. They’re not open source so they can’t be ported by the community. The SoC isn’t documented, so the community can’t write open source drivers.

Sure, in the end the whole thing might get reversed engineered. But it took years to get stable open source drivers for Broadcom WiFi cards.

Please search/read the forums – all this stuff have been gone over time and time again, but to repeat AGAIN, Broadcom/Foundation will be recompiling closed drivers as necessary when abi’s change. The Foundation will continue to supply working kernels. If you want a non-supported kernel then that is YOUR lookout – you will be using non-standard code which is not guaranteed to work – jsut as if you had rooted your Android device for example. The kernels supplied by the Foundation WILL work with the advertised features.

I doubt it’s even possible to reverse engineer this stuff btw.

This isn’t going anywhere so I’ll wrap up:

I wasn’t talking about the electrical or physical specs of the SoC, but about the Technical Reference Manual, documenting the capabilities and how to use them, like TI has for the SoCs used in BeagleBoard, or Freescale has for i.MX53, etc.

I understand why this SoC was chosen for Raspberry Pi. It’s probably the best compromise. But you should admit that this isn’t a non-issue and it sounds like the Raspberry Pi foundation has a strategy in place so that most users won’t be affected if all goes well. Put this in a blog post and maybe you won’t need to repeat yourself so often.

As for when Broadcom has done something similar in the past, alecthegeek has mentioned their WiFi drivers. Seriously, read on how that went.

Well, most of the currently useful capabilities for the SoC are already documented – the standard Linux API’s for OpenGL ES, OpenVG and EGL. There is also OpenMAX for the encode stuff, but that’s a pain so there is documention to be done there. Docs for the GPIO etc will be provided. SO I’m really not sure (apart from encode decode) wht you issue is with documentation.

As to the Wifi stuff, years ago, and not the same thing. There is a big difference between trying to use a Wifi chip and using a complete board based on a SoC. I’ll agree, Broadcom don’t have a stellar rep for producing either drivers or docs for their chips in the past – basically they are a profitable business and wanted to stay that way and that means big custom only. Although their attitude is changing internally you’ll be pleased to hear, and the Raspi project is be a good influence in that respect.