As much as I like the Raspberry Pi (no, I really do!), the graphical chip on this can only be better than the NDA nightmare of the RPi. It hasn't impacted me personally, but a few friends who are using it for specific use cases have had the problem when designing their own bootloader. Interested in getting my hands on one, but now all I need is time...
I've dug a little bit, and it looks like I'm a bit late. Broadcom did indeed give the keys to developers for the VideoCore IV, and a while ago. Yes, I haven't worked on RPi for some time. Previous to this, we had no idea how the chip worked, and we relied solely on a blob. So I stand corrected, things have indeed changed since my time. Thankfully! My bad.
The Raspberry Pi is the ONLY ARM based SOC that has fully documented the "graphical chip", there is no NDA ! I have no idea why you think there is.
The RPI GPU has a disassembler that can be used to on the "proprietary" boot loader (not very proprietary when you can disassemble it) to see exactly
what is needed to build your own.
Are people allowed to do that? I'm wondering it that gets classed as reverse engineering (which is not legal in some countries).
Furthermore, even if one did have the right to disassemble, they couldn't publish the disassembed code or share it with anyone, since I don't recall raspberry pi. org extending any license to allow that.
That could certainly make development of a custom bootloader awkward if you can't share with your team what you've found in the proprietary bootloader.
While we're on the subject of things that make development awkward on the Pi, I recall the information to make use of the CSI/DSI ports is still not available, making life difficult for anyone who
wishes to use their own hardware over those interfaces..
And of course the lack of full schematics, which causes issues.
In my ARM book, I talked about the RPi (version 1) and the bootloader, with an example of how to write boot code. I had multiple exchanges with ARM because it was a very delicate subject. I ended up publishing about 20% of what I had originally written, no-one wanted to go close to that subject.
The problem is, most documentation/tutorials online are often written just for one SBC, e.g. Raspberry Pi or BBB, and do not mention that its likely the code will work on all platforms. It is particularly
irritating when APIs even have the word 'pi' in the function names, when in reality they may work on other platforms too. Maybe it is information hiding, or maybe the developers of the documentation/tutorials didn't know.
Anyway, for I2C, the easiest way is to check in the /dev folder, if there is an entry called i2c-1 or i2c-2 or something. If so, then one of these will provide driver based access to the I2C pins on the connector, and the
access should work in any language with any library provided it uses the driver (which isn't often mentioned anywhere in the documentation but could be visible in the source code).
I don't know which language you wished to use, but (for example) for C programming the access is via the 'ioctl' function. Just to make it slightly higher-level (but still fairly low-level) I wrote some wrapper functions to
have an easier-to-understand API for I2C. It is available here, in the files i2cfunc.h and i2cfunc.c :
(to see how it is used, the file lcd3-test.c could be examined). In short, to use I2C with this wrapper library, these are some of the functions that are available:
i2c_open
i2c_write
i2c_read
i2c_close
(the full list and short documentation is in the i2cfunc.h file, it is mostly self-explanatory to be honest).
It doesn't handle everything but handles things like the repeated start which some online tutorials etc miss.
Reverse engineering is legal in the US. If you live in a country (?) where it is not, don't.
I said nothing about publishing the disassembled code, I said they could use that to write their own boot loader. It doesn't make much sense to publish
specs that allow the disassembler to be written and then keep people from using it but this certainly wouldn't be the first irrational thing the RPi foundation
has done (see The lack of schematics below). AFAIK if there is no explicit declaration that you can't publish the disassembled code of the boot loader in
the license then you can. But anyone thinking about doing this should carefully check the license and also check with the RPi foundation first.
"That could certainly make development of a custom bootloader awkward if you can't share with your team what you've found in the proprietary bootloader."
There is a well known technique for that where the functions of the code discovered by one team that has access to the disassembled code is described
to another team that does not have access to the code and they write code to execute those functions. Since they have never seen the code they can't
have copied it. This technique was used to clone the original IBM PC BIOS and I'm sure a lot of other code since then.
The lack of schematics is also a continuing problem for me. Since most of the hardware interfacing is done through the GPIO connector and most
of the SOC hardware is documented it's not a show stopper but it is IMHO it's just plain stupid. And there has never been a rational explanation from
the RPi foundation as to why they stopped doing this. The only one I can think of is to keep others from cloning RPis using the Broadcom SOC
but they already have complete control over the distribution of the SOCs and have shown no signs of letting anybody else use them so obviously
it must be something (?) else.
I thought the CSI/DSI interfaces were part of the GPU but I don't know if they are in the GPU documentation or not. From what I've heard so far from
you and others the answer is not.
I will also add one more problem. AFAIK the USB on the SOC uses proprietary hardware IP that Broadcom has a license to use but not to distribute
so it is not documented making writing your own drivers problematic at best. All of the code that was written to improve USB bandwidth problems
had to be written by a person employed by Broadcom because of this.
Interestingly they did initially publish the schematics for the very first Pi revision 1, but they got some flack for not engaging the community for peer review of the schematics before they released thousands of boards on the public.
Subsequently it was discovered they'd made a mistake and fed power to a pin on an IC that wasn't expecting it, causing unexpected behaviour. (The discovery of the mistake was made by the community). It was after that that they ceased with the schematics, although as we've seen there are more reasons than we can count on our hands why its needed, and yet not much has been done about it for years.
