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

Re: Broadcom BCM2835 SoC

Sun Aug 07, 2011 6:05 pm


TBH, I'm not aware of anyone who genuinely open sources all of their multimedia.
At least AMD and Intel do.


I believe that they don't open source the firmware blob running on the chip itself - just the drivers (which don't usually do any real work). Please correct me if I am wrong!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5202
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: Broadcom BCM2835 SoC

Sun Aug 07, 2011 6:12 pm

You're right, Jamesh. :)
Director of Communications, Raspberry Pi

KanjiMonster
Posts: 9
Joined: Sat Aug 06, 2011 10:12 pm

Re: Broadcom BCM2835 SoC

Sun Aug 14, 2011 1:30 pm

Quote from jamesh on August 7, 2011, 19:05

TBH, I'm not aware of anyone who genuinely open sources all of their multimedia.
At least AMD and Intel do.


I believe that they don't open source the firmware blob running on the chip itself - just the drivers (which don't usually do any real work). Please correct me if I am wrong!

Yes and no. There's a binary blob firmware blob, but it's rather small and does low level things like basic hardware setup (mostly on the physical level), the driver does the majority of the work (and directly talks to the device).

This is the same situation with many wifi chips, they require a minimal firmware blob for basic setup, but the whole 802.11 "logic" is still in the driver, not in the firmware blob.

With that I don't have much of a problem.

The most important difference to the way it is done on the Raspberry Pi as far as I have understood it is that the firmware blob is OS independent - nothing stops me from writing my own driver for these device, since all I need is to upload the firmware blob to the designated area of the device, and then I can "use" it (by writing to its registers).

But with a userland binary I can't do that. I'm limited to whatever you chose to support (or probably what Broadcom chose - porting drivers to other OS's isn't a very gratifying task, and you usually don't do it unless you get money from it if you are doing it commercially).

Will you provide the appropriate binaries for e.g. Android? NetBSD? Linux userland with current and future uClibc (which doesn't promise ABI compatibility through releases, just API compatibility)?

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

Re: Broadcom BCM2835 SoC

Sun Aug 14, 2011 8:16 pm

The binary blob I believe is downloaded to the GPU at boot time (by the bootloader I think - the architecture of the SoC means the GPU boots first, and this then boots the Arm). The open source drivers on the Arm then provide a message and data passing system to the GPU which then does the work.

So the blob is OS independent, you just need to implement the message passing system (Eben mentioned it elsewhere - it's called VCHIQ) on the OS of your choice and you would have access to the features of the GPU. However, how you make the bootloader run a different OS I don't know.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
ukscone
Forum Moderator
Forum Moderator
Posts: 4155
Joined: Fri Jul 29, 2011 2:51 pm
Contact: Website

Re: Broadcom BCM2835 SoC

Sun Aug 14, 2011 8:32 pm

Quote from jamesh on August 14, 2011, 21:16
However, how you make the bootloader run a different OS I don't know.

i may be talking out of my rear end but this is how i assume it'd work using u-boot/barebox if there is a version for the particular ARM flavour the ARM processor is.

--
1. the GPU powers on
2. Has the required firmware loaded and executed on it
3. the GPU loads a file called kernel.img from the sdcard into memory address 0x00000000
4. the GPU setups up all the various ARM registers to their required values
5. the GPU passes execution to the ARM processor from memory address 0x00000000 via an ARM reset instruction
6. the bootloader ( the kernel.img file -- u-boot/barebox) loads a linux kernel (or elf binary) into some area of memory
7. the bootloader does any messing around with gpio or registers it needs to
8. the bootloader passes execution to the loaded binary (kernel or elf)
9. hurry up and wait for a login prompt if linux distro being run, if elf binary hurry up and wait for it to do it's thing.

as far as i know currently we won't be using steps 6, 7 and 8 but we could if we wanted to for things like loading a rootfs/linux kernel from a usb drive or loading another os rather than linux

Cafe
Posts: 62
Joined: Thu Jul 28, 2011 2:22 am

Re: Broadcom BCM2835 SoC

Mon Aug 15, 2011 4:27 am

I find this topic so informative. Thanks Michael for starting it. Big thanks KanjiMonster for the probing questions. And thanks to Liz and jamesh for the responses.

Liz: KanjiMonster's questions and observations are the kind of things that have me concerned about the closed nature of the multimedia bits. I have expressed this concern in a couple of posts in a different topic. (Of course, KanjiMonster is way more eloquent than me.)

Svartalf
Posts: 596
Joined: Fri Jul 29, 2011 6:50 pm

Re: Broadcom BCM2835 SoC

Tue Aug 16, 2011 4:14 am

Quote from jamesh on August 7, 2011, 19:05
I believe that they don't open source the firmware blob running on the chip itself - just the drivers (which don't usually do any real work). Please correct me if I am wrong!

Heh...you're about to stand corrected... ;)

There's two sets of drivers within the context of Linux OpenGL and X11. There's the DMA and memory management part- the one you refer to. It resides in the Kernel, typically, and is properly GPLed.

Then there's the userspace component that comprises the state trackers for 2D and 3D acceleration, defined by the X11 and OpenGL drivers. In the case of Intel, they're bankrolling a good portion of the Gallium3D development and they have their state trackers for each and every GPU they have, save the one they licensed from Imagination that's labeled the GMA500 intended for the Atom series (Which the Linux community sort of is very disappointed in Intel over...), as open source drivers. In the case of AMD, they've provided most of the techincal information and employ two to three developers to help the FOSS community develop their Gallium3D support for Radeon devices.

Sorry, but they really DO have FOSS stuff- and it's the full deal. It's just not complete in some cases for some lines of parts yet.

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

Re: Broadcom BCM2835 SoC

Tue Aug 16, 2011 9:39 pm

Quote from Svartalf on August 16, 2011, 05:14
Quote from jamesh on August 7, 2011, 19:05
I believe that they don't open source the firmware blob running on the chip itself - just the drivers (which don't usually do any real work). Please correct me if I am wrong!

Heh...you're about to stand corrected... ;)

There's two sets of drivers within the context of Linux OpenGL and X11. There's the DMA and memory management part- the one you refer to. It resides in the Kernel, typically, and is properly GPLed.

Then there's the userspace component that comprises the state trackers for 2D and 3D acceleration, defined by the X11 and OpenGL drivers. In the case of Intel, they're bankrolling a good portion of the Gallium3D development and they have their state trackers for each and every GPU they have, save the one they licensed from Imagination that's labeled the GMA500 intended for the Atom series (Which the Linux community sort of is very disappointed in Intel over...), as open source drivers. In the case of AMD, they've provided most of the techincal information and employ two to three developers to help the FOSS community develop their Gallium3D support for Radeon devices.

Sorry, but they really DO have FOSS stuff- and it's the full deal. It's just not complete in some cases for some lines of parts yet.

There's still code running on the GPU that is proprietary I would think - or do the drivers access the HW blocks directly?

It doesn't really matter what those guys do to be honest. On this device, there will be FOSS drivers that talk VCHIQ message passing to the GPU, on which will run a binary blob. It just so happens that in the architecture of the Videocore, it uses a set of hardware blocks and multiple processing units that accelerate various features, these are all coordinated by code running on the GPU processors itself, not the driver. This stuff is set off by the VCHI messages from the host (the Arm).

At this stage the code running on the Videocore is proprietary Broadcom, but since end user have no real need to change it (actually, any real need to change it - and I guarantee it is very complex - over 1MB of binary code) that really makes no difference for users of the board. One advantage of the software scheme running on the Videocore is that you can add and change functionality by updating the binary blob, with no change to the drivers.

I'd like to see an OpenCL interface to the blob as the processing on the GPU is very very fast, but that would be a lot of work, both for drivers and on the Videocore side. Might look in to it...
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
Emanuele
Posts: 180
Joined: Wed Aug 03, 2011 5:28 pm
Contact: Website

Re: Broadcom BCM2835 SoC

Tue Aug 16, 2011 9:51 pm

Quote from jamesh on August 16, 2011, 22:39
I'd like to see an OpenCL interface to the blob as the processing on the GPU is very very fast, but that would be a lot of work, both for drivers and on the Videocore side. Might look in to it...

To be honest, I wouldn't care much about the source of the binary blob (I've skimmed over the Intel drivers, there's a lot of code in there, and I don't see what I would gain from studying it in detail). Now, having an OpenCL interface, that I would care about. But I understand it's a lot of work.

KanjiMonster
Posts: 9
Joined: Sat Aug 06, 2011 10:12 pm

Re: Broadcom BCM2835 SoC

Thu Aug 25, 2011 11:14 am

Quote from jamesh on August 16, 2011, 22:39
It doesn't really matter what those guys do to be honest. On this device, there will be FOSS drivers that talk VCHIQ message passing to the GPU, on which will run a binary blob. It just so happens that in the architecture of the Videocore, it uses a set of hardware blocks and multiple processing units that accelerate various features, these are all coordinated by code running on the GPU processors itself, not the driver. This stuff is set off by the VCHI messages from the host (the Arm).


So if I understand you right, the proprietary blob is only running on the GPU/Videocore (basically a "firmware" for it), and everything on the host/arm side (kernel + user space) is actually open source?


I'd like to see an OpenCL interface to the blob as the processing on the GPU is very very fast, but that would be a lot of work, both for drivers and on the Videocore side. Might look in to it...

Well, that exactly would be the advantage of having it open sourced (with appropriate documentation); you could just let the community do this by themselves ;)

But I understand that Broadcom won't let you.

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

Re: Broadcom BCM2835 SoC

Fri Aug 26, 2011 12:15 pm

Quote from KanjiMonster on August 25, 2011, 12:14
Quote from jamesh on August 16, 2011, 22:39
It doesn't really matter what those guys do to be honest. On this device, there will be FOSS drivers that talk VCHIQ message passing to the GPU, on which will run a binary blob. It just so happens that in the architecture of the Videocore, it uses a set of hardware blocks and multiple processing units that accelerate various features, these are all coordinated by code running on the GPU processors itself, not the driver. This stuff is set off by the VCHI messages from the host (the Arm).


So if I understand you right, the proprietary blob is only running on the GPU/Videocore (basically a "firmware" for it), and everything on the host/arm side (kernel + user space) is actually open source?


That is my understanding.



I'd like to see an OpenCL interface to the blob as the processing on the GPU is very very fast, but that would be a lot of work, both for drivers and on the Videocore side. Might look in to it...

Well, that exactly would be the advantage of having it open sourced (with appropriate documentation); you could just let the community do this by themselves ;)

But I understand that Broadcom won't let you.

It would require some people very acquainted with the VideoCore and its various cores (it's a multiple custom core device in itself) and HW blocks, and the only people like that work for Broadcom! Also, to work on it you require a custom compiler, assembler, debugger, and expensive JTAG's etc.

There is a lot of very clever and proprietary stuff in there (HW and SW) which could be copied by competitors if it was out in the open, which is why it remains a binary blob. And why the Videocore remains top of class in what it does.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

Michael
Posts: 340
Joined: Sat Jul 30, 2011 6:05 pm

Re: Broadcom BCM2835 SoC

Sat Aug 27, 2011 8:04 pm

Gert confirms it is the BCM2835. Yay!

User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5202
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: Broadcom BCM2835 SoC

Sat Aug 27, 2011 8:05 pm

:) I'm *very* pleased we've finally been able to release that snippet.
Director of Communications, Raspberry Pi

Michael
Posts: 340
Joined: Sat Jul 30, 2011 6:05 pm

Re: Broadcom BCM2835 SoC

Sat Aug 27, 2011 8:28 pm

Any idea how long before the datasheet and TRM will be available for public consumption?

User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5202
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: Broadcom BCM2835 SoC

Sat Aug 27, 2011 8:29 pm

Not at the moment, I'm afraid. We'll let you know as soon as we know ourselves.
Director of Communications, Raspberry Pi

KanjiMonster
Posts: 9
Joined: Sat Aug 06, 2011 10:12 pm

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 2:48 pm

Quote from jamesh on August 26, 2011, 13:15
Quote from KanjiMonster on August 25, 2011, 12:14
Quote from jamesh on August 16, 2011, 22:39
It doesn't really matter what those guys do to be honest. On this device, there will be FOSS drivers that talk VCHIQ message passing to the GPU, on which will run a binary blob. It just so happens that in the architecture of the Videocore, it uses a set of hardware blocks and multiple processing units that accelerate various features, these are all coordinated by code running on the GPU processors itself, not the driver. This stuff is set off by the VCHI messages from the host (the Arm).


So if I understand you right, the proprietary blob is only running on the GPU/Videocore (basically a "firmware" for it), and everything on the host/arm side (kernel + user space) is actually open source?


That is my understanding.



This sounds to me like you are only guessing from what others said and don't know it for yourself.

Could perhaps a developer with first-hand experience confirm or deny this?



It would require some people very acquainted with the VideoCore and its various cores (it's a multiple custom core device in itself) and HW blocks, and the only people like that work for Broadcom! Also, to work on it you require a custom compiler, assembler, debugger, and expensive JTAG's etc.



These people do not only work for Broadcom; there are many with the appropriate skills working on and around the Linux kernel. If there's proper documentation (source code optional ;)) they will come.


There is a lot of very clever and proprietary stuff in there (HW and SW) which could be copied by competitors if it was out in the open, which is why it remains a binary blob. And why the Videocore remains top of class in what it does.

That's still protected by patents even when opened, so competitors still couldn't just copy it (at least not without potential legal consequences).
Not opening it also doesn't really put a stop on competitors finding out how it works; there are services that will analyse chips for you.

User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5202
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 2:58 pm

Dude - Jamesh *is* one of the developers. Read around the board a bit more carefully next time.
Director of Communications, Raspberry Pi

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

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 3:30 pm

Quote from KanjiMonster on August 30, 2011, 15:48
Quote from jamesh on August 26, 2011, 13:15
Quote from KanjiMonster on August 25, 2011, 12:14
Quote from jamesh on August 16, 2011, 22:39
It doesn't really matter what those guys do to be honest. On this device, there will be FOSS drivers that talk VCHIQ message passing to the GPU, on which will run a binary blob. It just so happens that in the architecture of the Videocore, it uses a set of hardware blocks and multiple processing units that accelerate various features, these are all coordinated by code running on the GPU processors itself, not the driver. This stuff is set off by the VCHI messages from the host (the Arm).


So if I understand you right, the proprietary blob is only running on the GPU/Videocore (basically a "firmware" for it), and everything on the host/arm side (kernel + user space) is actually open source?


That is my understanding.



This sounds to me like you are only guessing from what others said and don't know it for yourself.

Could perhaps a developer with first-hand experience confirm or deny this?



It would require some people very acquainted with the VideoCore and its various cores (it's a multiple custom core device in itself) and HW blocks, and the only people like that work for Broadcom! Also, to work on it you require a custom compiler, assembler, debugger, and expensive JTAG's etc.



These people do not only work for Broadcom; there are many with the appropriate skills working on and around the Linux kernel. If there's proper documentation (source code optional ;)) they will come.


There is a lot of very clever and proprietary stuff in there (HW and SW) which could be copied by competitors if it was out in the open, which is why it remains a binary blob. And why the Videocore remains top of class in what it does.

That's still protected by patents even when opened, so competitors still couldn't just copy it (at least not without potential legal consequences).
Not opening it also doesn't really put a stop on competitors finding out how it works; there are services that will analyse chips for you.


Hello, one of the developers here....well, sort of....

re: the team working on the chip. I'm sure there are a few smart people out there, who, after a couple of years training would be able to work on some of the more complex parts of the Videocore. I've worked in various areas in it for three years, and most of it is still a mystery to me. There are a lot of custom HW blocks which are not found in any other chip - and in order to use them you need to know about them. The codecs are a case in point, and some of the HW accelerated parts of OpenGL etc. The team here in Cambridge is about 100 people, covering hardware and software design, so there is a lot of experience here. There are a few ex-Videocore engineers out there, but not many.

Patents are a good protection, but you cannot patent everything (whatever Apple would have you believe) - it's not cost effective. It's cheaper to maintain secrecy over the HW and SW design than to fight patent wars. Put it like this, if another company copied part of the GPU, then stayed closed source, Broadcom might never know they had ripped off their code/HW design, so you wouldn't be able to fight a patent action anyway.

And good luck to a chip analysis firm who can figure out how a Videocore works by staring at it, in a sensible timescale (i.e. years).

I think that the FOSS or not status of the Linux side libraries is still being discussed, so I may have been premature in saying they would be FOSS (hence my statement 'That is my understanding'), but I think the explanation above should be enough for most people to persuade them that it is not actually necessary for them to be FOSS for the majority, if not all, the users, since there is very little they could do to them to make any difference anyway. If it works, and works as fast as it can, you really don't need access to the source, since the only reasons for access would be for making improvements or fixing bugs. And since Broadcom are fixing bugs and improving it all the time anyway.....
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

Svartalf
Posts: 596
Joined: Fri Jul 29, 2011 6:50 pm

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 3:39 pm

Quote from jamesh on August 30, 2011, 16:30
If it works, and works as fast as it can, you really don't need access to the source, since the only reasons for access would be for making improvements or fixing bugs. And since Broadcom are fixing bugs and improving it all the time anyway.....


Ah...but what do you do when they phase out the VideoCore IV? Who'll make fixes for it then? To be sure, it's probably going to be on a date much further in the future than the relevant life of the R-Pi, but one of the KEY reasons GPL was done by Stallman was that he couldn't get code fixes for a still functioning, but unsupported device. Therein lies the rub.

(No, I'm not going to bitch about it being closed...but it's still a concern for the aforementioned reason...and it should be a concern for everyone, perhaps the main one on this subject...)

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

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 4:26 pm

Quote from Svartalf on August 30, 2011, 16:39
Quote from jamesh on August 30, 2011, 16:30
If it works, and works as fast as it can, you really don't need access to the source, since the only reasons for access would be for making improvements or fixing bugs. And since Broadcom are fixing bugs and improving it all the time anyway.....


Ah...but what do you do when they phase out the VideoCore IV? Who'll make fixes for it then? To be sure, it's probably going to be on a date much further in the future than the relevant life of the R-Pi, but one of the KEY reasons GPL was done by Stallman was that he couldn't get code fixes for a still functioning, but unsupported device. Therein lies the rub.

(No, I'm not going to bitch about it being closed...but it's still a concern for the aforementioned reason...and it should be a concern for everyone, perhaps the main one on this subject...)

Do the drivers you already have stop working when the VC4 is phased out?

One advantage of the SoC design is that you don't need to support odd driver combinations - unlike a PC where you can swap cards in and out to your hearts content, so you might put an old card in a new machine. So the need for drivers away from the standard platform is zero - and you already have drivers for the standard platform.

It also unlikely (not impossible) that people will find a bug in the VC4 after end of life. These devices are tested much more extensively than, for example, Nvidea graphics cards. For example, there are currently over 10 million devices with VC3's in; we occasionally get bug reports, which we fix, and these fixes moved to VC4 if appropriate. Same goes for any bugs reported for VC4 devices. Considering the complexity of these devices, we get relatively few reports - they are very reliable.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

Svartalf
Posts: 596
Joined: Fri Jul 29, 2011 6:50 pm

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 4:31 pm

Quote from jamesh on August 30, 2011, 17:26
Do the drivers you already have stop working when the VC4 is phased out?


I'll answer a question with another set of questions...

Does the latest AMD proprietary drivers support R200 chips right at the moment?

Do older versions of the drivers in question work correctly with the latest Kernel revisions?

If the answers to either of those are "no" (which they ARE...), then your question's a bit evading the issue I bring up here. ;)

Again, don't take this as bitching about "open drivers" and giving you all hell over them. That's not what I'm on about here. If you think it's only for fixing stuff that "breaks", you'd have the wrong impression. :D


One advantage of the SoC design is that you don't need to support odd driver combinations - unlike a PC where you can swap cards in and out to your hearts content, so you might put an old card in a new machine. So the need for drivers away from the standard platform is zero - and you already have drivers for the standard platform.


You're preaching to the choir there... ;)


It also unlikely (not impossible) that people will find a bug in the VC4 after end of life. These devices are tested much more extensively than, for example, Nvidea graphics cards. For example, there are currently over 10 million devices with VC3's in; we occasionally get bug reports, which we fix, and these fixes moved to VC4 if appropriate. Same goes for any bugs reported for VC4 devices. Considering the complexity of these devices, we get relatively few reports - they are very reliable.


Ah, but again... Would that driver be expected to survive an ABI change in the kernel. If the answer's "no"...again... ;)

hajj_3
Posts: 58
Joined: Mon Aug 22, 2011 7:42 pm

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 6:00 pm

Maybe broadcom may release the sourcecode once this chip is end of life? that would be a great way to keep everyone happy with minimal harmful repercussions for broadcom.

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

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 6:09 pm

Well, Linux ABI changes are rather out of our control, but you are under no obligation to upgrade your kernel to a point where it's no longer supported! In fact, you are more likely to run out of distros that support ARMv6 instructions than finding the GPU driver not working!

Let's say, that as sold, the device will work, and the GPU will be supported!

My hope is that the kernel side stuff will be OSS but that is a director level manager decision, so well out of my remit! That would mean users are safe from kernel changes. Since you cannot 'upgrade' a raspi to a different GPU, the other point is moot.

I expect (but I cannot give assurances - my personal view) there will be a steady stream of binary blob releases, as bug fixes are introduced, and more features added. One of the really cool features of the videocore is it's combination of software and hardware, so you can upgrade it - for example, by adding new codecs, or supporting new cameras, or new LCD panels. These software changes leverage the HW blocks to add new HW acceleration. Not possible (to the same extent) with other GPU's.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

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

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 6:24 pm

Quote from hajj_3 on August 30, 2011, 19:00
Maybe broadcom may release the sourcecode once this chip is end of life? that would be a great way to keep everyone happy with minimal harmful repercussions for broadcom.

Unlikely for the blob that runs on the Videocore - the tech for this moves between generations, so the VC2 contributed to the VC3 which in turn contributed a lot of design to the VC4, and I would expect that trend to continue.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
Contact: Website

Re: Broadcom BCM2835 SoC

Tue Aug 30, 2011 6:45 pm

Is there a block diagram that would be allowed for release?
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!

Return to “General discussion”