partis
Posts: 30
Joined: Sun Nov 13, 2011 9:54 pm
Location: North East England
Contact: Website

Re: Lack of Broadcom documentation

Sun Nov 13, 2011 11:09 pm

Hi all

As the RP is meant to be educational, how can one develop code outside of the supplied Linux OS, without datasheet(s)?

Is RP going to supply some level of documentation which is not NDAed by Broadcom, such as memory maps etc? For example, GPU display information for simple bitmap access and not the indepth acceleration features.

Cheers

Gary
Gary Partis

User avatar
Jongoleur
Posts: 1179
Joined: Thu Aug 11, 2011 12:47 pm
Location: O'erlooking the sea, and all those effin windfarms...

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 12:31 am

Perhaps I'm being excessively thick, but why would the target audience for the Pi really need the sort of documentation you talk about?

As I understand it, one of the key reasons of the Pi project is to "encourage children to explore programming". Given this aim, and the sort of tools mentioned in conjunction with it, I fail to see why they'll need access to low-level information, let alone be able to use it effectively.

If you have ideas about using the Pi for a project that goes beyond this, indeed WAY beyond this, then I suppose you'd need to engage with the Foundation and Broadcom at a level far deeper than merely posting in this forum. :-)
I'm just a bouncer, splatterers do it with more force.....

tcumming
Posts: 8
Joined: Mon Nov 14, 2011 1:24 am

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 1:31 am

I second the need for documentation. What if there is some really cool hw feature that is dying for a device driver that doesn't exist? We won't even know that cool hw feature even exists w/o documentation. What if there is a device driver that is broken, or doesn't work the way I need it for my project? I don't think I'm speaking for myself, and kids nowadays are doing pretty amazing stuff - specially if given the opportunity.

User avatar
Jessie
Posts: 1754
Joined: Fri Nov 04, 2011 7:40 pm
Location: C/S CO USA

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 2:07 am

I agree. I have brought this up in other threads before, and others have made it sound like the request is unreasonable. It is just common practice for the other SOC companies to provide at least enough info to use the gpio pins, dma, irqs, or hardware timers.

I don't think it would help most programmers, but it would help some of us.

obarthelemy
Posts: 1407
Joined: Tue Aug 09, 2011 10:53 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 3:10 am

It's not unreasonnable, just very unlikely to be satisfied. Broadcom keep their stuff close to their chest, but the Pi guys are doing their best to get some info and pass it on. The bitmap GPU access is probably the only thing that will eventually surface.
No point in keeping asking / whining, it's out the the Pi Foundation's hands, and they're well aware of the issue already.

User avatar
Burngate
Posts: 6370
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 11:41 am

Within a week of getting my BBC-B, I was poking random numbers at the screen-memory, just to see what it looked like (it also showed that the Ferranti chip was broke - had to have it replaced!).
OK, so on the Pi the OS will handle stuff like putting things on the screen, but I'd still like to be able to prod things, just to see what happens (my wife objected when I prodded the Yorkshire pud, but putting smiley faces on it amused me).
So, yes, I'd like a list of what's where on the memory map that the GPU looks at, even though I won't know how the GPU does what it does with what it finds there. To a certain extent, I don't really care how it does it, just so long as I can predict how it'll react when I prod it in a certain way.

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 12:05 pm

People asking for this sort of stuff woefully underestimate the complexity of the device. The GPU is very VERY complicated. The chances of someone (not already employed by Broadcom to work on the chip) being able to write a driver or to fix existing drivers is quite low (not impossible, just very low). Also, the likelihood of finding a bug is also pretty low (this chip and drivers are already in product on the shelf so a very heavily tested), and when they are found will be fixed by Broadcom themselves, or Raspi themselves depending on the source of the driver.

As for asking for memory maps, it doesn't really have one in the traditional sense. Communication to the GPU from Arm is handled by message passing, not prodding memory locations. On the GPU cores themselves there is a memory map - it's between 5 and 10k different registers, and the datasheet for those is 600 pages and rather overwhelming. And being able to pope and prod those won't be of much use with out the experience of knowing what to do with them. And the comp[iler isn't available (it's not standard)

This isn't a BBC micro.

Also, there are no cool features on the chip we haven't mentioned! Some areas you cannot get at yet (the camera interface for example - you don't want to do that at home - v. complicated requiring a lot of knowledge/experience), but that will come in time.

I've worked at Broadcom on this chip for three years - there are still vast swathes of it I have no idea about. I still need to ask help from other people here with more experience. I'm not trying to put people off, I encourage experimentation. Just trying to get across the sheer complexity of the device and the difficulty of programming for it for the uninitiated!
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.

mateli
Posts: 17
Joined: Thu Aug 18, 2011 6:59 pm
Contact: Website

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 1:11 pm

Quote from jamesh on November 14, 2011, 12:05
People asking for this sort of stuff woefully underestimate the complexity of the device. The GPU is very VERY complicated. The chances of someone (not already employed by Broadcom to work on the chip) being able to write a driver or to fix existing drivers is quite low (not impossible, just very low). Also, the likelihood of finding a bug is also pretty low (this chip and drivers are already in product on the shelf so a very heavily tested), and when they are found will be fixed by Broadcom themselves, or Raspi themselves depending on the source of the driver.

As for asking for memory maps, it doesn't really have one in the traditional sense. Communication to the GPU from Arm is handled by message passing, not prodding memory locations. On the GPU cores themselves there is a memory map - it's between 5 and 10k different registers, and the datasheet for those is 600 pages and rather overwhelming. And being able to pope and prod those won't be of much use with out the experience of knowing what to do with them. And the comp[iler isn't available (it's not standard)

This isn't a BBC micro.

Also, there are no cool features on the chip we haven't mentioned! Some areas you cannot get at yet (the camera interface for example - you don't want to do that at home - v. complicated requiring a lot of knowledge/experience), but that will come in time.

I've worked at Broadcom on this chip for three years - there are still vast swathes of it I have no idea about. I still need to ask help from other people here with more experience. I'm not trying to put people off, I encourage experimentation. Just trying to get across the sheer complexity of the device and the difficulty of programming for it for the uninitiated!

Perhaps we should stick to the AMD APU:s which the MESA team know how to do all that stuff, if Broadcom GPU:s are so much more complicated then the radeon?

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 2:32 pm

Well there's a multitude of reasons. Price, power, size, compatibility.

I mean why should we sacrifice a superior option just because it's more complicated? Well, we say more complicated, but the complication exists at a level we don't and can't access. All access we need to the device is still available via open sources, it's just the binary blob itself we can't touch. Jasmesh's point here is that even if the broadcom corporation opened the GPU for us all to play with, we couldn't do anything with it so there's no point being upset that we don't have access to it ;)
Dear forum: Play nice ;-)

AlanCox
Posts: 31
Joined: Thu Nov 10, 2011 7:11 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 3:33 pm

Quote from abishur on November 14, 2011, 14:32
I mean why should we sacrifice a superior option just because it's more complicated? Well, we say more complicated, but the complication exists at a level we don't and can't access. All access we need to the device is still available via open sources, it's just the binary blob itself we can't touch. Jasmesh's point here is that even if the broadcom corporation opened the GPU for us all to play with, we couldn't do anything with it so there's no point being upset that we don't have access to it ;)

I think thats misleading - "superior" in education is rarely a closed box with arbitrary walls. If you want that then UK kids might as well us their phones for hacking on in java/dalvik. They'll all have perfectly programmable phones in a couple of years anyway.

There are two things being muddled here, and IMHO dangerously so.

The first is the internal architecture of the GPU. Complicated, closed, and it could equally have loaded its blob off a ROM as the internals of many PC GPU devices are. There is a ton of stuff internal to all these GPUs that you don't even realise exists on PC class hardware. It's not documented, its probably extremely device dependant and you simply don't need to know about it any more than you do about the CPU microcode.

The second is the messaging you send it. That's akin to the 'poke this address' interface and the message based documented parts of the AMD APU, the Intel i9xx, the 3Dfx, 3Dlabs, VIA and SiS chips plus various other products.

For the PI to work those messages (at least for the PI specific firmware) need to be open and documented. Without this the PI project will spend the rest of its life having to keep porting its non-free driver and blob to new kernels (we won't accept it upstream with a closed user space blob because we can't test it, we aren't sure if its legal given how derivative works law behaves , and we don't want your compliance liability if it turns out to be a problem)

It's also upstream policy that with non-free stuff loaded we just ignore all your bug reports, close them and refer you to the vendor of the non-free bits. The PI foundation has the ability to debug it, nobody else does - so its their problem and we can't help - and in this case neither will the PI community be able to, only the little cabal of designers behind the project.

Alan

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 4:05 pm

Quote from AlanCox on November 14, 2011, 15:33
The second is the messaging you send it. That's akin to the 'poke this address' interface and the message based documented parts of the AMD APU, the Intel i9xx, the 3Dfx, 3Dlabs, VIA and SiS chips plus various other products.

For the PI to work those messages (at least for the PI specific firmware) need to be open and documented. Without this the PI project will spend the rest of its life having to keep porting its non-free driver and blob to new kernels (we won't accept it upstream with a closed user space blob because we can't test it, we aren't sure if its legal given how derivative works law behaves , and we don't want your compliance liability if it turns out to be a problem)
Hi Alan.

Good to see a senior kernel dev here. I was wondering if it was actually you.

It's been stated openly that at least the messaging part of the the GPU interface will be GPLed (it couldn't be otherwise, as it's kernel-space). That, I believe, gives the interface for setting up a "dumb" framebuffer with no blobs or binary-only drivers required. It was also mentioned some time ago that the foundation were interested in GPLing (or at least open-sourcing) their OpenGL (and, IIRC OpenVG) implementations.

Simon

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 4:12 pm

Quote from AlanCox on November 14, 2011, 15:33
For the PI to work those messages (at least for the PI specific firmware) need to be open and documented. Without this the PI project will spend the rest of its life having to keep porting its non-free driver and blob to new kernels (we won't accept it upstream with a closed user space blob because we can't test it, we aren't sure if its legal given how derivative works law behaves , and we don't want your compliance liability if it turns out to be a problem)

It's also upstream policy that with non-free stuff loaded we just ignore all your bug reports, close them and refer you to the vendor of the non-free bits. The PI foundation has the ability to debug it, nobody else does - so its their problem and we can't help - and in this case neither will the PI community be able to, only the little cabal of designers behind the project.

Alan


Well, I disagree. For the target audience of the Pi, as long as it works, it's fine. And it will work out of the box.

In fact even for the majority of others, it will be fine without publishing that stuff (I'm not saying it won't be published - I just don't know)

It is not a requirement to move to newer kernels (although Broadcom will be maintain the drivers for newer kernels for the foreseeable future). v3 kernel is already supported in house. What I find odd is the fact that the kernel keeps changing it's ABI which means recompiling EVERY driver. Never understood why that was necessary considering what a PITA it is. I'm sure there is a reason though, and I don't think it happens that often.

I'm not even sure its huge issue with the Raspi given its very low cost.

And please don't mistake the Pi foundation with Broadcom - the foundation itself does not have access to all the drivers (but because a number of people in the foundation work for Broadcom, stuff does get done).

Finally, this project would not be possible with other chips currently on the market - we get a big discount and a lot of technical support, which would not be forthcoming from other manufacturers - because of the Broadcom connections.
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.

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 4:17 pm

Quote from tufty on November 14, 2011, 16:05
Quote from AlanCox on November 14, 2011, 15:33
The second is the messaging you send it. That's akin to the 'poke this address' interface and the message based documented parts of the AMD APU, the Intel i9xx, the 3Dfx, 3Dlabs, VIA and SiS chips plus various other products.

For the PI to work those messages (at least for the PI specific firmware) need to be open and documented. Without this the PI project will spend the rest of its life having to keep porting its non-free driver and blob to new kernels (we won't accept it upstream with a closed user space blob because we can't test it, we aren't sure if its legal given how derivative works law behaves , and we don't want your compliance liability if it turns out to be a problem)
Hi Alan.

Good to see a senior kernel dev here. I was wondering if it was actually you.

It's been stated openly that at least the messaging part of the the GPU interface will be GPLed (it couldn't be otherwise, as it's kernel-space). That, I believe, gives the interface for setting up a "dumb" framebuffer with no blobs or binary-only drivers required. It was also mentioned some time ago that the foundation were interested in GPLing (or at least open-sourcing) their OpenGL (and, IIRC OpenVG) implementations.

Simon

Although the messaging code will be GPL'd, the actual message content tends to be specific to each service provided by the GPU (e.g. EGL, GL, Max, framebuffer etc) - I'm not sure that would automatically be open since it's not actually source code. And having thought about it, that should be fine with regard to kernel updates and ABI changes. The driver is OSS, but the libraries that use it currently are not. Since the lib->driver interface will stay constant, the kernel underneath can do what it likes.
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.

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 4:34 pm

Edit: Oops. Jamesh and tuffy beat me to responding (teach me to keep my window open too long before reading posts!) My post is responding to Alan's post at the end of the last page /Edit

Ah, in this case I was using superior to refer to the actual comparison of capabilities, features, raw power, compatibility with ARM at all, price, and form factors (not saying that the broadcom wins on every point, but that when these factors are taken on the whole the broadcom is the superior choice... which is why the r-pi team chose it ;) )

As for the rest, yeah, that's exactly what I'm saying :)

Yes, we will have to grab the kernel from the r-pi team, or wait for someone to do it and put a torrent up of our favorite distro for us, but I freely admit, I don't care about that :D I get why and the reasoning for people caring about that, but I just don't, it's just not an issue to me. To me needing to grab an update kernel is no worse than me having to grab an update to my bios, or an update to my phone. Yeah, I have to do it through the manufacturer, not that big a deal (to me :P )
Dear forum: Play nice ;-)

AlanCox
Posts: 31
Joined: Thu Nov 10, 2011 7:11 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 4:49 pm

Quote from jamesh on November 14, 2011, 16:12
Well, I disagree. For the target audience of the Pi, as long as it works, it's fine. And it will work out of the box.


Well time will tell that. I think until then we can but disagree 8)


kernel is already supported in house. What I find odd is the fact that the kernel keeps changing it's ABI which means recompiling EVERY driver.


The kernel is source code, it makes it enormously more flexible. WIndows has masses of driver compatibility gloop that we don't have to keep because we can rewrite anything we need as we need. That's why its still a true descendant of the same kernel not the fifth complete rewrite

It also means we can rewrite APIs that have conceptual security problems whereas the proprietary folk get to do mind bending hacks.

It's not a problem for upstream drivers generally because the basic house rule is 'you change an API you fix the fallout either yourself or as a group because the group has consensus to fix it.'. In practical terms it tends to mean that stuff once upstream stays building and just needs testing. I think once any PI required bits are upstream you'll find those particular bits mostly look after themselves.

The lack of ABI, and the slowly reworking of the API is a concious choice from many years of working this way and has shown its worth repeatedly. It does mean that drivers need to be built to match a given kernel but as they are usually always included it's not a big problem.

For the non included cases it can be a bit messier. Dell developed a set of tools to handle this called DKMS and which various folks do use with Fedora to build and keep out of tree modules nicely matching their kernel.

That may well be useful for the PI graphics out of tree driver packaging if Fedora based is the final way the PI goes. Then users will just need the graphics blob and the GPU driver from elsewhere and the GPU driver can use DKMS to help keep itself correctly compiled up.


And please don't mistake the Pi foundation with Broadcom - the foundation itself does not have access to all the drivers (but because a number of people in the foundation work for Broadcom, stuff does get done).


Good point, and likewise I've dealt with Broadcom people in other areas where they've sometimes opened stuff up or worked to find good solutions for all.


Finally, this project would not be possible with other chips currently on the market - we get a big discount and a lot of technical support, which would not be forthcoming from other manufacturers - because of the Broadcom connections.

I recognize this. Likewise I recognize that there is a ton of stuff in the GPU itself which Broadcom are not going to open up. The question is how to build a good interface between the secret Broadcom internals and the public space, which encompasses some of the useful interfaces (mode set, block move, block copy, composite, perhaps video playback and often much harder the 3D)

You actually get a fast smooth 2D interface simply by exposing the block move and copy, and preferably the compositing operations on a 2D surface. How much it helps varies according to the CPU speed and particularly CPU write performance (and to some extent read performance) to the memory involved. On a device with relatively weak CPU/memory performance the 2D ops are a big win.

Console mode benefits a lot from either screen base movement (to do full screen scrolling) or 2D copy/move. But it's unclear whether for most users that is an optimisation of the slightest relevance.

Alan

Bacan
Posts: 347
Joined: Sun Sep 25, 2011 10:03 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 4:54 pm

If quality educational software is desired, then some developers of that software will need access and understanding of the inner control methods and means.

Will an eleven year old that is running a graphic animation application, for the first time, need to understand video memory mapping of the RAM for a buffer. No. Will the software creator of that application need to understand that, and a whole lot more. They better!

Until the R-Pi hardware API is release, we are all just chasing our tails. Will everything about the Broadcom chip be release, not if I was on the Broadcom side of the table. Will the required stuff be freed for use. Yes, just not as fast as some of us would like.

The above is my opinion, not that of the Foundation or Broadcom.
I've been wrong before, and my track record has shown me right more often than I'm wrong.

tcumming
Posts: 8
Joined: Mon Nov 14, 2011 1:24 am

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 6:03 pm

Actually, I agree that the gpu tweaking may require a team of engineers that are also the same engineers that designed it (i.e., broadcom engineers). When I responded for a need for documentation, I was not referring to the gpu, but all other possible things. An extra few i/o pins? A cpu temperature sensor? A bug in a spi channel?

I also agree with the comment that we may never see this documentation. I understood that I was griping about something we may never get. Maybe rpi-II will use a chip from someone who'll be more open (if they exist )?

tom

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 6:21 pm

There isn't another SoC like this that's open. I can assure you we looked *very* hard for one!
Director of Communications, Raspberry Pi

ErvKosch
Posts: 82
Joined: Thu Sep 01, 2011 3:40 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 6:23 pm

Maybe rpi-II will use a chip from someone who'll be more open (if they exist )?

I think Ras-Pi is going to be exclusive to Broadcom. Most (if not all) the people working the project are employees of Broadcom. I get the impression that this is a their version of the TI BeagleBoard - an internal project by the employees to show off what they (employees and the company's product lines) can do for developers on a budget.

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 6:59 pm

I have to correct you on that - first off, only one of the six trustees works for Broadcom. A few Broadcom engineers are supporting us by working on the project in their spare time, but that's because they're friends of ours who are enthusiastic about what Raspberry Pi is doing, not because it's a Broadcom project (it emphatically isn't). It happened that the BCM2835 was the best SoC for the job, on price, feature set and power; but that's *absolutely* not to say that we only plan to use Broadcom hardware in the future.

We did a lot of shopping around and looked very hard at a number of SoCs before choosing this one - it wasn't chosen because Eben had worked on it, although I do suspect one of the reasons it's as good as it is has to do with the fact that Eben's a very, very good engineer and chip architect. Raspberry Pi wouldn't be what it is without him either.
Director of Communications, Raspberry Pi

Nobody
Posts: 16
Joined: Tue Nov 01, 2011 8:07 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 7:25 pm

Well, maybe sometime in the future someone will write a history how the Raspberry Pi came into being. Including a list of contenders and calculations showing why the BCM2835 made the race.

Pretty please.
*making puppy eyes*

ErvKosch
Posts: 82
Joined: Thu Sep 01, 2011 3:40 pm

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 7:32 pm

Sorry Liz, I meant nothing negative. From the pieces I've gleamed from the message board and news articles I must have gotten the wrong perception.

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

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 7:35 pm

@Nobody - the calculations are dead simple - if you go and investigate chip prices, you can do them for yourself. Tegra 3, for example, costs more than the entire cost of the board and also consumes more power than the BCM2835.
Director of Communications, Raspberry Pi

partis
Posts: 30
Joined: Sun Nov 13, 2011 9:54 pm
Location: North East England
Contact: Website

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 8:51 pm

Quote from partis on November 13, 2011, 23:09
blah blah from me

I started this thread as I was unable to source any documentation.

If this is truly a project to bring the 80s style computing to the younger generation, then low level access is paramount. Linux based GUIs etc are 10-a-penny. This system is cheap and that is the only obviously advantage.

Having a closed environment means young potential engineers of tomorrow have no access to what computing is really about. They need to know the fundimentals, not how to use another OS, spread sheet etc.

No doubt other experienced engineers on this forum know what is required to create an OS from scratch (ie. not just another Linux port), my self included.

Others stating that the datasheet(s) is 'complicated' are having a laugh. That is why we are engineers! :-/

All I want is a bootstrap (which appears straight forward), a frame buffer, control of the mass storage and control of the GPIO/SPI/I2C et al. Pretty much like I required back in the early 80s when I was a young kid, with a passion for electronics and software engineering.

I really hope RP and/or Broadcom make something available, even if it is only a set of linkable libraries to allow access to the above.

Cheers

Gary Partis
Gary Partis

tcumming
Posts: 8
Joined: Mon Nov 14, 2011 1:24 am

Re: Lack of Broadcom documentation

Mon Nov 14, 2011 10:08 pm

I'll second the notion of learning fundamentals. I cut my eyeteeth on an Altair 680b writing code in assembly language, and kids now days should have that option. Ditto w/ writing / poking at device drivers. However, they won't be experienced engineers (yet!), and for a beginner engineer writing (or even tweaking) a driver for a serial port will be actual work.

I've also worked on teams that were privy to the secret docs we're talking about, and even with an experienced team and the right docs, many of the projects were non-trival. One reason being is that the details aren't always documented and the details weren't always pretty (read - broadcom just might not want anyone to see what a mess it is!).

I'm suggesting that it would be a good compromise with Broadcom to get specs on everything except the GPU (or some similar compromise). It'd be even cooler if some contributor came up with a, "here's how to write a device driver for your rpi" tutorial.

Return to “Other projects”