Update: A lot of people are asking when revision 2.0 boards will appear in the wild. They’ll be filtering out over the next month as the last stocks of the revision 1.0 at each distributor and in each geography are exhausted. I’m aware of at least one person who has received a revision 2.0 board already (from Farnell, in the UK).

We don’t believe that the changes are large enough to make it worth “holding on” for revision 2.0, unless you have a specific requirement to add an audio codec or you need mounting holes for some industrial application.

In the six months since we launched Raspberry Pi, we’ve received a lot of feedback about the original board design. Over the next few weeks, we’ll be gradually rolling out a new revision 2.0 PCB which incorporates some of the most popular suggestions. You can determine which board revision you have by typing cat /proc/cpuinfo at the command line and looking up the hardware revision code in the following table:

Model and revision

Code(s)

Model B Revision 1.0

2

Model B Revision 1.0 + ECN0001 (no fuses, D14 removed)

3

Model B Revision 2.0

4, 5, 6

There has been a small change to the GPIO pin out of revision 2.0, to add ARM JTAG support and to present a different I2C peripheral from that which is (heavily) used on the camera interface. Users wishing to produce portable GPIO code should either avoid using the these pins, or add code to check the board revision and behave appropriately.

Reset

A reset circuit has been implemented, although in the standard build the required header is not fitted. Users wishing to use this circuit should fit an appropriate header to P6. Shorting P6 pin 1 to P6 pin 2 will cause the BCM2835 to reset.

USB Output Power

The resetable fuses protecting the USB outputs have been removed. This feature was implemented on some later revision 1.0 PCBs by replacing the fuses with links; revision 2.0 permanently implements this modification. It is now possible to reliably power the RPI from a USB hub that back feeds power, but it is important that the chosen hub cannot supply more than 2.5A under fault conditions.

JTAG Debug Support

Two GPIO pins have been interchanged to allow a missing debug signal (ARM_TMS) to appear on P1 pin 13.

Originally the connections were:

CAM_GPIO [BCM2835/GPIO27] routed to S5 pin 11

GPIO_GEN2 [BCM2835/GPIO21] routed to P1 pin 13

The new connections are:

CAM_GPIO [BCM2835/GPIO21] routed to S5 pin 11

GPIO_GEN2 [BCM2835/GPIO27] routed to P1 pin 13

I2C Support on P1/P6

The primary and secondary I2C channels have been reversed.

Originally the connections were:

SCL0 [BCM2835/GPIO1] routed to P1 pin 5

SDA0 [BCM2835/GPIO0] routed to P1 pin 3

SCL1 [BCM2835/GPIO3] routed to S5 pin 13

SDA1 [BCM2835/GPIO2] routed to S5 pin 14

The new connections are:

SCL0 [BCM2835/GPIO1] routed to S5 pin 13

SDA0 [BCM2835/GPIO0] routed to S5 pin 14

SCL1 [BCM2835/GPIO3] routed to P1 pin 5

SDA1 [BCM2835/GPIO2] routed to P1 pin 3

Version Identification Links

The four GPIO signals originally used for version identification have been removed. These were never read by the system software and were redundant.

Additional I/O Expansion

To utilise GPIO signals released by the removal of the version identification links, a new connector site P5 has been added. This carries the four GPIO signals [BCM2835/GPIO28 – BCM2835/GPIO31] named GPIO7 – GPIO10 respectively, along with +5V0, +3V3 and two 0V. Currently this connector is not populated.

This GPIO allocation provides access to one of:

SDA0, SCL0 (Operating independently of P1 SDA1, SCL1); or

PCM_CLK, PCM_FS, PCM_DIN, PCM_DOUT or I2S; or

Four GPIO signals.

This connector is intended to be a suitable attachment point for third-party clock and audio codec boards, and is pinned to be mounted (ideally) on the underside due to connector clash. Pin 1 is marked with the square pad (top left – looking from the top).

+5V0 Leakage from HDMI

Some users have found that connecting an unpowered Raspberry Pi to an HDMI television interferes with the correct operation of CEC for other connected devices. This was fixed on some later revision 1.0 PCBs by removing the ESD protection diode D14; revision 2.0 fixes this issue by connecting the top side of the diode to +5V0_HDMI.

SMSC +1V8

The SMSC 1V8 power has been disconnected from the system supply.

Mounting Holes!

Two 2.5mm (drilled 2.9mm for M2.5 screw) non plated mounting holes have been provided to assist with ATE test mounting. Positions of these holes relative to the bottom left of the PCB (Power Input Corner) are:

Corner: 0.0mm,0.0mm

First Mount: 25.5mm,18.0mm

Second Mount: 80.1mm, 43.6mm

Warning: If used to permanently mount the PCB – do not over tighten screws or drill out to fit larger screws, as this will lead to damage to the PCB.

I ordered my board from Farnell and definitely got a UK made new revised version of the board. I’ll take a guess that the turnaround time from manufacturer to sale is refreshingly short! Possibly even ‘Just in Time’ manufacturing?

How are people getting their RPI so quickly? I ordered mine on June 29th and have not yet received it! That’s almost 4 months! Yet, others are ordering and getting them right away? Is RS/Allied not a real company and I’ve been scammed out of my cash?

I think it sort-of casts a shadow over Gert’s suggestion from ages ago that the easiest way to connect a simple input microswitch is between pin 3 and ground (because of its always-connected pull-up resistor), though technically he did say GPIO_0 and ground, which is still true – it’s just that GPIO_0 is now on pin 14, not 3.

I assume this means that pins 13 & 14 are now the ones with permanent pull-up resistors?

Is there any timescale on when these will be available from RS etc? i.e. when released then will they be manufacturing to the new spec?

At some point I’m thinking of getting another pi, the 2 existing ones are in use but use existing case designs but the mounting holes would be of use as it’s going to need a custom case – it’s going to be running a radio telescope alongside several arduinos hence the custom case requirement?

If it’s going to be a couple of months then fine – it’s just would be nice to know when they are shipping the newer revisions

We expect they’ll be filtering out over the next month as the last stocks of the older design at each distributor and in each geography are exhausted. I’m aware of at least one person who has received a revision 2.0 board already (from Farnell, in the UK).

I ordered a Raspberry Pi from Farnell on 30/8/12 and received a version 2 board yesterday. Which surprised me as it was showing out of stock when I placed the order.
Comparing it to my older board from RS I’d noticed the P5 pads and had been trying to find out what they were.
Somehow I completely failed to notice the mounting holes until I read your post!

Rather than change the current boards, would there be any sense in a “Model C” with a higher spec (and higher price tag), or would that just divert the team’s attention to unnecessary issues?
I would certainly be interested in a board with more RAM (say 1GB), gigabit Ethernet and a SATA interface or two. The question is whether you could get the volumes on a board like that, and whether that kind of board would cannibalise the sales volumes of the current board, killing the economies of scale which are currently being reached.

I expect the internal answer will be along the lines of “when it’s possible to add them and still achieve the $35 price point.”

Of course, as with the 512MB RAM upgrade, we’ll only be notified once the upgrades are ready to ship (so they don’t have oodles of people cancelling their orders in advance of the new release, resulting in a bunch of unsellable old revision boards).

Thank you for fixing these (minor) bugs! A new HW revision was of course the right choice.

But as a newbie to low-level electronics etc. I’m in the same boat as Frapé.
To me this all sounds like “Everything regarding the GPIO, and some voltage related stuff etc. is now completely different! Watch out!”.
Doesn’t this totally break compatibility with most self-made HW addons, and the corresponding code and thousands of postings, wiki entries, HowTos etc all over the net?
Is the community now basicly split in half, so that there will be HW/SW for specific revisions?
Will we see more projects with warnings that go like “only tested with Rev. 1!!! If you have Rev. 2 you are on your own! Patch it yourself or whatever. I don’t care.”
Do (less experienced) people now have to look twice and tripple before doing anything, or they will fry their RasPis or connected HW?

Let me try. Firstly, nothing relevant to the user has changed on the voltage side: this is just housekeeping. Tutorials which rely on the particular I2C exposed on the GPIO will need to be updated to query the board revision number: this was a hard decision, but it will significantly improve the usability of the board for the small number of people who want to do both camera and high-rate I2C, and allow kernel-mode non-intrusive debug. Doing this check is pretty trivial, and we will be encouraging (e.g.) Adafruit to take this approach in their tutorials.

We’re confident this is the only time we will have to make this sort of change.

The original GPIO connector had five pins labelled “do not connect” to provide for possible future additional I/O connections. Now that the 4 new I/O nets actually go to a separate connector, does that mean we can rely on the “DNC” pins on P1 being connected to ground?

So to be specific, I gather we may now rely on these P1 GPIO pins to remain as shown in the Rev1 schematic.
P1-04: +5V0, P1-09: GND, P1-14: GND, P1-17: +3V3, P1-20: GND, P1-25: GND. We should update the wiki to that effect.

The mounting holes are a definite improvement but not ideal from a placement point of view. Are there plans for future revisions to have have them in more conventional places, like the corners of the board? One small additional question, does this new revision have the tank capacitor mounted in through holes?

OK! I’ve updated wiringPi and I’ll push a new revision as soon as I’ve done some more testing – the upshot is that anyone using wiringPi’s own “pin” numbering scheme won’t be affected as long as they install the new wiringPi and re-link their application.
Any programs using the “traditional” GPIO pin numbers will need to be changed if they used the GPIO pin 0 & 1 (I2C) and third general purpose GPIO pin – aka BCM_GPIO 21 – they’ll now need to change that to 27.

I suspect that one will affect a lot of people (more than the I2C pins changing), so a lot of code will need changing for people who’re using that particular pin.

I was hoping that we could have a switch on the board that would allow us to chose between using Power over Ethernet (PoE) or USB to power the RPi. Could this be added to the board in a subsequent revision?

I would like to have several Raspberry Pi’s around my house doing video surveillance and other tasks, and I wanted them to be plugged into ethernet with PoE powered by an uninterrupted power supply (UPS).

Software intended to work on both board versions will need to read the board id and conditionalize its access to the GPIO lines. If there is enough demand, we may implement a transparent translation in the kernel drivers, at which point the only applications affected will be those which directly map and poke the GPIO registers from userland.

Those who use the “standard” /sys/class/gpio will be affected as gpio21 is now gpio27 – that’s going to be the main issue and while the kernel drivers could swap them over, I think it would just cause even more confusion – what kernel version, what board version, etc….

I too wish there was a way to tell which revision I will get. I want to design a pi-plate using I2S.

I am an in the UK and would order through Farnell. Their lead time is currently 3-weeks, does that mean they are awaiting a delivery of the new revision boards? Given that they have already delivered one rev2, if I order now there is a good change it will be a second revision?

I ordered a one from Farnell on 03/09/12 and it said there was a 3 week wait. In my impatience I bought one off ebay as 3 weeks seems like an eternity for a new toy only to get an email from Farnell on 05/09/12 saying my order had been desptached.

3 weeks? You’re lucky — I ordered one from RS online in June, at the end of August I got an email saying there would be a 9 week delay! I now assume this has something to do with the revisions. Luckily (do far), the Pi is for my Daughter’s birthday in October but I had hoped to get up to speed with it over the the summer, but 9 weeks from August 28 is cutting it awfully close.

I also ordered at the end of june, and apparently had the order held up by my ordering a case at the same time. I have heard nothing from RS, except that my payment was made on June 26. Presumably when RS gets arround to fullfillment of the RPI and case, they will now be shipping Rev. 02.

Might be worth making an order with Farnell it’s a few quid more than RS but I was willing to pay the extra for quicker delivery as RS was saying 9 weeks. I’ll let you know when mine turns up and what version it is. If you get stuck I have a new sealed one coming from ebay that I might be willing to part with.

It’s nice with the board bugfixes and improvements! Are all the changes
listed here concerning the “Model B Revision 2.0 4”?

What changes are planned for the versions 5 and 6?

Could the SD-reader 1,8 V voltage needed for UHS-I speeds be provided
with a future board revision? Swap space would definitively benefit from
UHS-I speed from the SD-card. Obviously random access write performance
is very important as well as well as the maximum bandwidth.

“We don’t believe that the changes are large enough to make it worth “holding on” for revision 2.0, unless you have a specific requirement to add an audio codec or you need mounting holes for some industrial application.”

Could you please expand on “add an audio codec”

Will revision 1 of the boards not be able to add audio codecs (I’m guessing hardware decode, like the MPEG2 and VC1 codecs recently announced)?

You are mixing up software coder decoders (codec), and hardware coder decoders, (also called codec’s) yes I know its confusing!
A software codec takes an encoded stream and decodes it (or vice-versa), a hardware codec is a chip that converts a diigital signal (in this case an I2S signal) and converts it to analog sound signals (and vice-versa)

The new board brings all the signals needed for an I2S interface for a codec chip together on one new GPIO header. The signals are also available on the older board but took some precision soldering of wires to the board.

With an I2S codec you can create high quality audio out and and also audio in (a feature that was missing, you might have a need for it example for skype) it can also provide for optical out, and surround

MJ, any news on any sound I/o expansion being developed for the new p5 connector?
I have tried to use a USB (cmedia?) Soundcard to run ‘soundmodem’ (for ax25 packet), and both have stopped working – not visible in ‘lsusb’.
So off to pcworld to complain,i think…..

Yay for removing the USB fuses!
The worst problem I’ve had with the Pi has been USB devices that fail to work, even if my main supply could provide plenty of power. I altered my Pi to bridge the fuses, now it works great with a webcam in one port and a Wifi stick in the other.
So glad this was changed in the new revision!

Here I have been working away modifying my RasPi to make it Back-power, testing it for around a month, and you just up and change the PCB so it will do it out of the box. Thats just not Right! Quit reading thew dang post in your own forum! ;)
lmao

And yes it’s tempting to think this is a Revision 2, but I now understand that in Eben’s table the table header “code(s)” has to be interpreted as “code reported by /proc/cpuinfo under the confusing name ‘Revision’.” … Pffew.

So, as I understand it now: there is a “Raspi model revision” and a “/proc/cpuinfo Revision” , and those numbers do not correspond 1-on-1. Attempt:

I guess the “I2C Support on P1/P6” heading in your blog post should actually say “I2C Support on P1/S5”?

Now that the USB output fuses have been removed, has there been any change at the MicroUSB power-input/fuse side? i.e. if powering a new Rev2 board via the MicroUSB port (and a suitably powerful PSU) is it possible to get the full 500mA from each USB port?

Yet another JTAG connecter?
I’m out of electronics for a while – but isn’t there a thing called “JTAG-CHAIN” in the IEEE-Standard 1149.1, where ONE connector on the board can be used to accesses multiple devices?

This could probably free space and connectors for additional useful Features (GPIOs, Mounting holes, etc. ). – Probably too late now, but maybe to be put on the list.

A nice improvement IMHO could also consist in a variant change of the connectors.
ATM the RasPI lies like a hedgehog on the desk, needing cable attachments from all sides, takes much room, uncomfortable access – the common case solutions cannot ease this.
If changing the connectors to standing versions, the board would only have one SD access from the side and all other accesses from the top – allowing much better cases (board could ‘stand’ in a case, ports point backward). Height differences of connectors aren’t a problem, since all board parts should be below that ‘accesss-level’ of the connectors which appear outside of a case.
Comments?

If you like to have shield boards, you could put them to the bottom with a direction changed GPIO connector.
The usual operation of the board would by upright, top would be back, (if not cased, take some clamps) – so no top heaviness…

Would be interesting to see cat /proc/cpuinfo listing from one of the new release 2 boards. It is easy to understand the release 1 version revision numbers 2 or 3. But it is a lot more difficult to understand the new release 2 revision numbers 4,5,6. It is lottery or which one of those is used? Is there any difference between 4, 5 or 6 boards? Or do they all start from 4 so that 5 and 6 are reserved for further minor changes?

I haven’t soldered anything on my own raspberry pi, though I have soldered on various other development board such as arduinos, philips FM receiver demos, Yamaha demo boards, etc etc and it always went without issues. The finest pitch you can typically hand-solder without any experience or microscopes is like 1mm or 0,5mm; so it really shouldn’t be an issue.

It’s a bit scary to solder on a 6-layered PCB board, as the individual layers are much thinner compared to 2-layer boards, though the top and bottom layer on multi-layered board are typically about as thick (as in thickness of copper clad) as double-sided stuff. Some people advice to heat up a soldering iron til you can melt the thin, then disconnect it from mains, do the soldering within a minute and be done with it. Though the bcm2835 was designed to withstand solder reflow-oven temperatures, so I doubt it matters much

SMSC +1V8:
I’m impressed that there haven’t been found any larger oopses than the ones listed. The 1V8 one, though, makes me wonder. I made a similar mistake once (tying the internal voltage regulator output of phy to a shared supply), and on some boards the pass transistor in the phy killed itself trying to do the work of the much larger external regulator.

Is there a lucky coincidence, such as a sufficiently low current limit in the ‘9512, that prevents damage?

Was there a big problem using a usb powered with older boards? So far I’ve only used my Pi (1.0 I think) a little, but I do so by plugging it into a powered hub (2 cables, one from the Pi usb port to the hub usb in, and another from a hub usb port to the Pi’s power in).

In this case, it is a good change I believe. The BoM can be decreased a little by removing the polyswitches, the end-user gets slightly more stable power over USB and there’s only a mildly increased chance your house will burn down from keeping the raspberry pi running over night :D

Did anybody think of a way to power the board via other means than the micro USB?

One interesting variant of the board would be one where USB, Network, GPIO, Audio, Composite and Micro-USB are not soldered in, but supplied separately. Thus the RPi could be used as part of another device. The devices’ main board would have all the needed connectors (except the HDMI, which should remain as such ports can be problematic to re-route) and mount the RPi using pin connectors. With such a setup, a cheap and standardized linux system could control another appliance, something that would ease development of linux-controlled systems where low unit counts would make the use other solutions difficult and expensive. By allowing the main board design to provide the RPi interfaces as internal or external interfaces the appliance can be build and designed in a very flexible way.

All this could be done now by de-soldering the connectors from the RPi, but as the micro-USB is SMD, there is no easy way to power the RPi from the appliance’ main board.

That is exactly what I’d like to avoid. We have a class of devices here that would profit from having a strap-on linux system for control, but including the RPis board design (once it is available) into the main board is a bad idea, as it would require quite complex manufacturing (like the piggybacking of the broadcom chip). I believe that a lot of smaller companies are in a similar situation. An “Embedded RPi” as descibed above would enable the RPi to cover a whole new market segment – small and medium technology businesses that so far avoided linux for its hardware complexity.

Any plans to provide solder points for the two extra USB ports on the LAN9514 chip? Some hardware-fiddling folks might be interested in replacing the LAN9512 with the 4-port version (which, according to the datasheet, should be downward compatible).

You could squeeze more connectors on one side but they would be cramped, you would have to have more layers to the board to allow the routing so more expensive and you would still not be able to get all of them in. Trust the experts!

I don’t get it. Couldn’t the RPi always be powered from a USB Hub? Or any 5V supply that provides sufficient current? Do you actually mean that the RPi can now be powered (reliably) via one of the two USB-A ports instead of just the micro-USB port?

If so, this is much better. micro-USB is mechanically weak due to its small size and wears out a lot sooner than USB-A. Also, since the Ethernet and USB are right next to each other, it means if you want to use the RPi as a remote server, you only have to plug cables into one side of the device. This makes mounting and housing the device a lot simpler.

micro usb was chosen only because EU regulations have made these types of wall-warts extremely prevalent in Europe. Though if you look at the rated connect/disconnect cycles, micro USB doesn’t differ much from regular usb connectors. They’re both rated for about 1000-1500 disconnects lifetime. It’s not a lot, though it’s plenty

Hope this can be worked around with revision 2.0 boards, so they don’t have this “short out” issue that seem to be absent from the initial 1.0 boards.

For those with rev 0003 boards, perhaps replacing the 0 ohm resistors replacing F1 and F2 with low-ohmage resistor would prevent the short-out/reboot (perhaps resulting from a current surge charging internal power supply of wifi adapter?).

Late to the party…but it is nice to see that all that complaining about the board structure I did previously has been heeded. It was even worth tolerating the harsh words from Liz about my complaining about this obvious need. Thank you..

I might actually be able to use the product now, as I gave up on the RasPi after getting my first eval unit in June from Element 14 and being frustrated trying to come up with a way to permanently mount in for remote applicatiion, I’ll take another look now.

In the meantime, China has made scads of the MK802 Android PC on a stick unit, which matches the original RasPi stick prototype design (which is what attracted me in the first place) presented in a flash drive like linear form factor and comes with a case and power supply at $49 USD. So, there’s stiff competition now.

Still despite my misgivings about eh original RasPi and the lack of things like mounting holes and the ability to have a linear wiring throughput, I’ll take another look…I may still be able to make a viable product out of it for the application I had in mind.

Thanks for redesigning the product to be more mount friendly. I never did want to try the orange shoo-goo or whatever it was as stuff like that invariably fails in use when you need it the most (like extreme temperature swings).

That’s right, Anthony. We added holes *just because you asked for them*.

I remember having to interact with you very well, and we came down on you because you were repeatedly damned rude, not because you were asking for something. I am delighted to hear that you have got over your “misgivings”. Stay polite and you can stick around.

BTW I may have come off as rude then because I felt mounting holes were very important, and I didn’t feel like you took the issue seriously then. Obviously, you have taken it seriously now by inclusion in Rev2, and I’m sure there must have been many more people like myself that brought up the issue. I made no claims as being the only one complaining, though I might have been the most vocal at the time.

Nothing is ever accomplished by a reasonable man – George Bernard Shaw

I’m sorry if I sounded unreasonable. Congratulations for listening to your user base and improving the product.

I’m making a case for Rpi, but although I have the 3D model, the mounting holes are not well defined, as they cut the connector from the SD card.!!
In Catia model or step!!

Two 2.5mm (2.9mm drilled for screw M2.5) non plated mounting holes provided to Have Been assist with ATE test mounting. Positions of These holes relative to the bottom left of the PCB (Power Input Corner) are:

I have three of the newer boards, and reset on USB hotplug is problematic in my application. I have confirmed the problem by ‘scoping the 5V and 3V3 busses during hotplug and observing the transient voltage drop, and I have a solution to suggest should you release another board rev. It depends on IC2’s ability to work properly with 4.8 volts or so as opposed to 5 volts, and it may require replacing RG2 with a regulator that has a lower dropout voltage. But if these conditions can be met, it may be possible to hotplug USB devices without the Pi resetting.

First, insert a Schottky diode, (one chosen for the lowest possible forward drop at the current required), in series between the incoming 5 volt power feed and the 5 volt connection to RG2 and IC2. Second, add a decent-sized capacitor, (220uF might do the trick – testing is required), between the cathode of the Schottky diode and ground. This may maintain the voltage supplied to RG2 and IC2 at a high enough level, for a long enough time, to prevent memory corruption and/or reset. (The diode prevents the capacitor connected to its cathode from discharging through the temporary ‘short’ caused by current rushing into a USB device during plug-in).

I’d be happy to test this, but I don’t think I can – as far as I can tell the 5 volt connections are on an internal layer. And it may be moot – I don’t have specs on the Broadcom chip, so I don’t know what the specified voltage range is on the 5 volt pins. But I thought I’d pass the idea along in case it’s helpful – I’d really like to have hotplug capability!

In lieu of this, might you consider restoring the Polyswitches, (and/or subbing 1 ohm resistors), at the USB connectors? You could add removable shunt-type jumpers in parallel with these, so users can choose between full-current USB capability and hot-puggability.

In the meantime, I plan to scab a 4700uF cap onto the 5 volt supply input and cross my fingers, hoping to give my 2 Amp USB charger some help holding the voltage up during hot plugging.

When I initially commented I clicked the “Notify me when new comments are added” checkbox and
now each time a comment is added I get several e-mails with the same comment.
Is there any way you caan remove people from that service?
Cheers!