RPi rev 2.0 explained

It is really a great thing that they already released the schematics and gerbers for the new board !!

-J

jamodio wrote:

 

It is really a great thing that they already released the schematics and gerbers for the new board !!

Really???!!!  Woot!!!  Was that announced somewhere, or they just silently appeared somewhere?

As far as I can tell, the minimum increment on their version number seems to be 1 (not something like 0.5), so this is a rev 2, a minor revision. And they must have been working on it for while, since some are already in punters hands, so thinking back, the board changes must be probably 2-3 months old at least (to get through re-design, prototyping and testing etc), so even though they didn't announce anything, they have been working behind the scene to fix stuff for a while.  I guess that's how most companies work - can't think of many companies that actively announce problems in their product they are going to fix until after the event.

BB

OTOH, when you're moving I2C channels around and adding I2S, some software needs to know which rev it's running on and apologize profusely if it can't run on rev 1.x.

Not just software, it'll be a problem for hardware too

Has anyone seen any proper explanation of the reasoning behind moving the I2C channels ?  Not sure if I missed something, but I don't see anything in the datasheet to suggest there's any difference between them, so not clear why the switch was necessary.

Did a pinout of P5 get posted ?  Or do we have to wait for someone with a new board and a multimeter ?

It seems such a pity that they didn't align the network & usb sockets with this respin. My feeling is that this will never be fixed now, possibly so that they don't annoy case designers.

And to think I just dropped in to see if anyone knew if the lan9512 1.8v supply had been fixed.

Oh well, at least I don't feel so guilty about wanting to cast one in clear resin like http://runawaybrainz.blogspot.co.uk/2012/04/audio-crystal-cmoy-freeform-headphone.html anymore

The +1 increment is the number they burn on the OTP section of the BCM SoC.

According to their Revision numbering it contemplates a minor revision number, the new board is Revision 2.0.

I know MANY companies, even non-profits and large ones traded in public markets that provide advance information, erratas, and known issues reports and expected fixes and time frames when the fixes will show up on production units.

-J

The Blog article does not show any pinout for P5 and I didn't find any reference to it on the forum.

About the 1V8 error, Eben said "The SMSC 1V8 power has been disconnected from the system supply."

-J

Even switching the I2C is not really a major change.

Unless you're actually relying on I2C for something. 

It makes for quite a complex problem, especially when you get to a kernel that uses devicetree. That leaves you needing the bootloader to modify the supplied devicetree file prior to kernel boot, it can't be cleanly fixed in the kernel. So it probably leaves you to multiply up the combinations of Rpi-v1 or Rpi-v2 vs addon board designed for a Rpi-v1 or v2 vs SDcard with kernel that knows about v2 or not.  Oh, and a bootloader that knows about v1 vs v2 and what any addon board expects.

I was never keen on the BeagleBone idea of every addon board having a small I2C flash device on it which describes the required gpio details. However it now seems like a very good idea - apart from the I2C pins have moved so you would have challenges to read it!

Also it further breaks the idea of being able to use one SD card on any Pi you like.

The Blog article does not show any pinout for P5 and I didn't find any reference to it on the forum.

I put a comment on the post asking for it. Lets see if there's a reply..

About the 1V8 error, Eben said "The SMSC 1V8 power has been disconnected from the system supply."

So who has a thermal imager and can get hold of a v2 to see what difference it makes ?

Eben didn't provide much detail about why the switch of the I2C channels, perhaps they found something that was not working properly with the camera

using the secondary channel.

From the software side is not that a big deal if you somehow can read a variable that tells on which board rev you are running, which they did by burning a code revision number on the BCM SoC.

-J

From the software side is not that a big deal if you somehow can read a variable that tells on which board rev you are running, which they did by burning a code revision number on the BCM SoC.

Until you get a devicetree kernel...  at that point you need to know the version of the board, and whether the bootloader has already 'fixed' things for you.

I also saw mention that they'd consider a patch to current kernels to reverse the kernels view of the I2C channels - if there was enough demand.  So same problem, I know from the revision number I have a v2, but that doesn't tell me if the kernel has been patched or not. Therefore the only thing to do is to probe both I2C busses (hopefully ignoring the one connected to HDMI) to see if I can find the device I'm looking for.

Probing random things on the bus could be bad, the i2c-tools utilities are filled with warnings about it. Something gets confused and sends data for the camera module to HDMI and kills someones TV isn't going to go down well. Ok, maybe that's unlikely, but usual problem is that the majority of people getting a Pi are not the experienced engineer who'll get it right.

"Has anyone seen any proper explanation of the reasoning behind moving the I2C channels ?  Not sure if I missed something, but I don't see anything in the datasheet to suggest there's any difference between them, so not clear why the switch was necessary."

They wanted to get I2S working. If you look at the BCM2835 datasheet you will see that GPIO28-31 has on it the options of I2S or 4 GPIO or on two lines I2C0!

Now it seems like they saw the opportunity not to end up with boards connected to the 26pin GPIO connector just having RTC or I2S.

We at CJE Micros/4D have made an effort on our RTC/Temp Sensor to allow pass through of all 26 lines but the connector to do so is very expensive.

We have already worked out how we can fit a new design RTC/temp Sensor to the new connector, above the board or below ( though if above it will like our existing design make plugging into the DSI display connector difficult/impossible)

Makes good sense to me though it will mean having to do two versions of our boards as we would like to advantage of the new connector.

"Has anyone seen any proper explanation of the reasoning behind moving the I2C channels ?  Not sure if I missed something, but I don't see anything in the datasheet to suggest there's any difference between them, so not clear why the switch was necessary."

They wanted to get I2S working. If you look at the BCM2835 datasheet you will see that GPIO28-31 has on it the options of I2S or 4 GPIO or on two lines I2C0!

Now it seems like they saw the opportunity not to end up with boards connected to the 26pin GPIO connector just having RTC or I2S.

We at CJE Micros/4D have made an effort on our RTC/Temp Sensor to allow pass through of all 26 lines but the connector to do so is very expensive.

We have already worked out how we can fit a new design RTC/temp Sensor to the new connector, above the board or below ( though if above it will like our existing design make plugging into the DSI display connector difficult/impossible)

Makes good sense to me though it will mean having to do two versions of our boards as we would like to advantage of the new connector.

GPIO28-31 has on it the options of I2S or 4 GPIO or on two lines I2C0!

Ok, on I2S, but I2C0 is now shared with the camera connector.  If, as the blog post suggested, it's used 'heavily' by the camera it could end up not being the best place to put a RTC, never mind other stuff.

We have already worked out how we can fit a new design RTC/temp Sensor to the new connector,

You have the pinout for P5 ?

though it will mean having to do two versions of our boards as we would like to advantage of the new connector.

That's my point, you now need two boards.. How many existing Rpi are out there without P5 that won't be able to use the new version of your board ?

I'll be changing my designs to take account of the new connectors and pinouts.  But that's mainly because if one of my v1 boards ever fails it'll now be getting replaced with a v2