Home > Broadcom BCMxxxx, Hardware > Raspberry Pi 3 Model B Board Features a 64-Bit ARM Processor, Adds WiFi and Bluetooth Connectivity

Raspberry Pi 3 Model B Board Features a 64-Bit ARM Processor, Adds WiFi and Bluetooth Connectivity

February 27th, 2016 Leave a comment Go to comments

The Raspberry Pi foundation is working on yet another model of the popular Raspberry Pi boards, as the Raspberry Pi 3 model B board has showed up on the FCC website. The new board looks very similar to Raspberry Pi 2 model B, but adds on-board WiFi 802.11 b/g/n (2.4GHz only) and Bluetooth 4.0. Let’s play “spot the difference” with Raspberry Pi 2 at the top and Raspberry Pi 3 under.


Raspberry Pi 2 (Top) vs Raspberry Pi 3 (Bottom)

The processor looks the same as the BCM2836 quad core Cortex A7 SoC found on model 2 B, but one redditer claims it could be a 64-bit processor due to some MagPi ad. [Update: that’s the MagPi ad which confirms Raspberry Pi 3 will feature a 64-bit ARM processor @ 1.2 GHz. Thanks Gabe!


We’ll find the WiFi/BT chip antenna on the top left corner, and two through holes on the right of the 40-pin connectors, likely the RUN header for reset that can be found on the RPi2 where the chip antenna is now placed on RPi 3. So the through holes are not new, they’ve just moved it. All connectors have the exact same placement between the two versions. Let’s check out the other side of the board.


Raspberry Pi 2 (Top) vs Raspberry Pi 3 (Bottom)

The wireless module (likely Broadcom based) can be found just above the micro SD slot, and J5 connector is soldered. J5 is the JTAG connector, so it will probably not be soldered with the version that ships. The picture is not very clear but it looks like they’ve used the same Elpida B8132B4PB-8D-F RAM chip (1GB) as on Raspberry Pi 2. So although we can’t be 100% certain right now, the RAM appears to be the same, and the processor is still connected to a similar USB to Ethernet chip, so they’ve probably kept the same architecture, expect possibly for the CPU core. So the only major changes on Raspberry Pi 3 appears to be built-in WiFi and Bluetooth, and  64-bit ARM cores (likely Cortex A53).

Via Liliputing and HackerNews

  1. Johnny
    February 27th, 2016 at 11:50 | #1

    Still Broadcom? So likely still terrible media drivers? I think I’ll pass and look elsewhere.

  2. Ian Tester
    February 27th, 2016 at 12:46 | #2

    Of course it’s using Broadcom chips. Most of the RPi Foundation people are current or former employees of Broadcom. It’s practically a branch of the company. And they certainly get a discount on the chips.

  3. February 27th, 2016 at 12:47 | #3

    Maybe if add NAND unit and up memory speed to 2GB, it will be THE ROCK BOARD 😉

  4. boudyka
    February 27th, 2016 at 14:52 | #4

    Gigabit ethernet and usb 3.0 and bit of rendering oomph would change the universe at 70 quid I’m in 🙂

  5. Ali
    February 27th, 2016 at 15:43 | #5

    For some reason, there seems to be more resistors towards the top of the CPU on the RPi3, between the CPU and the Raspberry Pi logo. Could hint at at different CPU being used ?

  6. February 27th, 2016 at 16:27 | #6

    If they had just added WiFi and Bluetooth, they would have probably called it Raspberry Pi 2 Model C, or something similar. They’ve increased the version number, so I’m pretty confident a new processor will be used, and the guy on reddit seems to be onto something:

    The MagPi advert for the next issue lists 64 bit and 1.2GHz as a feature so its not the same SoC. Same amount of RAM though since there is a single RAM chip on the back which has the same part number as the RPi 2 RAM and nothing stacked on the SoC.

    RPi 3 = RPi 2 but with some number of 64 bit ARMv8(.1) cores and integrated 2.4GHz WiFi + Bluetooth. Everything else appears to be the same.

    So we just have to wait for the release of the next MagPi (which date would the be?) to find out the details.

  7. tkaiser
    February 27th, 2016 at 16:32 | #7

    Seems like a different BroadCom SoC: http://kaiser-edv.de/tmp/4U4tkD/Left_RPi2_Right_RP3.jpg So Allwinner’s A64 won’t be the slowest Cortex-53 any longer soon 😉

  8. Gabe
    February 27th, 2016 at 17:04 | #8

    Here is the MagPi advert:

  9. Ian Tester
    February 27th, 2016 at 17:14 | #9

    64-bit? Now that’s interesting. Until now, the only 64-bit ARM boards were either incredibly expensive server boards or the disappointing 96boards offerings. It’ll probably have Cortex-A53 cores, so no speed demon. But at least it’ll be much cheaper and widely available, and not squeezed onto tiny boards like 96boards.

  10. February 27th, 2016 at 17:32 | #10

    Thanks! Very useful.
    I’m pretty certain they’ll announce the board on Monday, because February 29 will be the 4th anniversary of the first Raspberry Pi board, so that would be timely.

  11. February 27th, 2016 at 17:33 | #11

    @Ian Tester
    There’s also Pine A64, but it’s not really available.

  12. tkaiser
    February 27th, 2016 at 17:37 | #12

    Where does this 64-bit hype originate from? I would assume they try to stay as compatible to the previous RPis so the hardware will be initialised by the VideoCore processor and then they will run ARMv6 code on Cortex-A53 maybe even using a 32-bit kernel. Cortex-A53 might be interesting if you optimise your code for ARMv8 (_then_ you get probably more performance) or use 64-bit features like more than 4GB RAM. This board has still only 1 GB RAM (32-bit address bus?) and still just a single USB2.0 connection to the outside. Wow.

    In this combination the move to Cortex-A53 will just be the same PR stunt as the last: http://whereismypizero.com

    If I would be interested in Cortex-A53 I would wait for the ODROID-C2.

  13. nobe
    February 27th, 2016 at 17:41 | #13

    Let’s hope the new soc will bring better IO.
    I also wonder how the RPI foundation and its community will handle the software optimization transition.

  14. tkaiser
    February 27th, 2016 at 17:57 | #14

    There’s still the LAN9514 USB hub with integrated Fast Ethernet used (check the FCC link and click on ‘External Photos’) so how should I/O improve (maybe they manage to deal with WiFi/BT through SDIO/UART instead of USB). And why should an ‘optimization transition’ happen? That’s maybe the greatest strength of the RPi: Everything the same on every board even if it’s slower than necessary 😉

  15. onebir
    February 27th, 2016 at 20:33 | #15

    Custom/new BCM chip, or are there already 64 bit ones matching the spec/likely price point?

  16. blu
    February 27th, 2016 at 20:44 | #16

    Just imagine if it turns out to be the new BRCM Vulcan ;p

  17. February 27th, 2016 at 20:52 | #17

    I like the following comment in the DTS file for Vulcan processor
    /* just 4 cpus now, 128 needed in full config */

    It also supports PCIe, so that’s not our boy here 🙂 It must be a server SoC, right?

  18. Chris Burton
    February 27th, 2016 at 21:09 | #18

    This came through via snail mail this morning https://dnshistory.org/dump/CPC%20-%20Computer%20World%20-%20March%202016.pdf BCM2837 (64bit quad core 1.2Ghz) / 1GB RAM / BMCB43143 WiFi & BTLE and no the order code doesn’t work yet.

  19. blu
    February 27th, 2016 at 21:11 | #19

    Right, it’s a high-throughput server chip, expected to compete with Cavium’s, AMD’s and Qualcomm’s.

  20. onebir
    February 27th, 2016 at 21:16 | #20

    BRCM BabySpock

  21. cortex-a72
    February 27th, 2016 at 22:49 | #21

    I’m glad for raspberry pi guys, for their new offering, good for them, wish them success, but really, if you wanna play with something 64-bit arm, then Odroid-C2 is a clear winner. 96boards and pine64 are both an abysmal.

  22. natsu
    February 27th, 2016 at 22:54 | #22

    odroid C2 shipping cost makes it obsolete, that’s the real problem

  23. Sander
    February 27th, 2016 at 23:44 | #23


    For me *the* 64-bit argument is … Docker.

    Docker is possible on ARM32 (I have it on my Raspi2) and other 32bit, but it is a bit of stepchild: only a few container images available in the Docker hub.

  24. RK
    February 28th, 2016 at 00:04 | #24

    Technically speaking, 64bit isn’t just ram. The buses – which are the major bottleneck when it come to graphics and communication – multiply in width too. So it’s much easier to write interpreters and implement garbage collection, concurrency and type safety when you have many large registers and a big, fat stack (and heap).

    Practically speaking, when servers, desktops, mobiles and embedded are all moving to 64bit architectures (x86-64 and ARMv8), not doing the same often means losing out on optimizations. Especially when you consider how Android is moving away form Dalvik and ART to the OpenJDK, leaving all those 32bit optimizations behind.

  25. Jesu
    February 28th, 2016 at 00:43 | #25

    Each comment was removed today, is related to pi 3. (from raspberrypi.org)
    Something must have made…
    2 night sleep and everything will be clean. 😉

  26. natsu
    February 28th, 2016 at 01:05 | #26

    the media decoder, any info about support of HEVC and VP 4K decoding ???

  27. Pete
    February 28th, 2016 at 01:46 | #27

    Hi Jesu .. I thought I was going mad … but your right the comment i wrote on the raspberry pi blog was edited! no reference to pi 3 …

  28. MarkW
    February 28th, 2016 at 03:09 | #28
  29. memeka
    February 28th, 2016 at 03:35 | #29

    most probably the pi3 will have the same GPU as before. just like the transition from pi to pi2, only the CPU cores will change. also, the bus does not get wider in 64 bit, the registers do. the pi3 will unfortunately still have the IO as bottleneck, as again will have one shared USB controller for network and all its 4 USB ports.
    i don’t foresee any HEVC, VP, 4k, or better performance in emulators such as ppsspp or n64 that rely on GPU.

  30. natsu
    February 28th, 2016 at 03:46 | #30

    in that case, we have to go ODROID C2 a much better and well balanced board after all, 16$ for shipping on top, but very well deserved

  31. February 28th, 2016 at 03:49 | #31

    Someone posted what’s apparently a page of the CPC catalogue on Reddit: http://i.imgur.com/exuZy58.jpg

    But it says “64bit quadcore ARM 7 processor”… ?

    Maybe it’s a 64bit … memory bus 😉

  32. onebir
    February 28th, 2016 at 04:04 | #32

    From catalogue processor is “BCM2837”, whatever that is…

  33. February 28th, 2016 at 04:07 | #33

    It’s BCM2836 (current Pi 2 processor) + 1 🙂

    I’ll eat my hat if this turns out to be a true arm64 processor.

  34. wired420
    February 28th, 2016 at 05:15 | #34


    The fact that you call the amount of memory the “memory speed”, tells us you don’t deserve to have this or any high tech device.

  35. Ush73
    February 28th, 2016 at 06:27 | #35

    Sounds greatvbut highly doubt same pricing.

  36. deets
    February 28th, 2016 at 07:21 | #36

    Catalog shown above puts it right around $35

  37. Nobody of Import
    February 28th, 2016 at 08:07 | #37

    JM, might want to get some sauce for the hat just in case. They WERE working on an A53 equivalent.

  38. February 28th, 2016 at 09:26 | #38

    Farnell datasheet for the Raspberry Pi 3 lists “64bit ARMv7″… http://www.farnell.com/datasheets/2020826.pdf

  39. Stephen
    February 28th, 2016 at 13:17 | #39

    It’s disappointing that it still only has 1GB of RAM. Hopefully it is still not LPDDR2 and they have at least upgraded it to LPDDR3.

  40. tkaiser
    February 28th, 2016 at 16:11 | #40

    Ok, 64-bit isn’t just ‘more RAM’ but wider buses. Since they now write ‘BCM2837 64bit ARMv7’ these wider buses seem all you get from the 64-bit transition? The same ultra slow 1GB LPDDR2 DRAM, still just one USB2.0 connection to the outside and their official USB WiFi dongle based on BCM43143 is now also onboard.

    Really no ARMv8 but Aarch64 ‘backported’ to ARMv7? No ATF (ARM trusted firmware) but proprietary hardware initialisation through VideoCore? If that’s the case this board isn’t even interesting for software devs trying to dive into 64-bit ARM development. 🙂

  41. Nz1
    February 28th, 2016 at 16:22 | #41

    I am wondering if 64bit computers need twice as much ram as 32bit computers.
    I know that arm used to have a thumb instruction set that somehow managed to shoehorn 2 16bit instructions into a 32bit word for 32bit processors, so that ram wouldn’t be wasted. I am not sure if they still do this or if it is part of Android or Linux or even if people bother with 64bit cpus.
    The problem is that ram is still relatively expensive so 64bit instructions that waste ram still matters. If there is not enough ram the 64bit board could run slower than a 32bit board with the same amount of ram.

  42. blu
    February 28th, 2016 at 16:48 | #42

    A 32bit ARMv8 is ok, but a 64bit ARMv7 makes absolutely no sense. Something was lost in translation.

  43. February 28th, 2016 at 17:34 | #43
  44. Jon Smirl
    February 28th, 2016 at 22:26 | #44


    Apps in 64b computers are a lot bigger than 32b ones. Just compare the same Linux app source code compiled for x86 and x86_64. It is because they drag around a lot of 64b numbers (addresses) that weren’t there before. But without 64b you aren’t going to get more than 4GB of physical memory. Bigger apps need more memory bandwidth, more cache area, etc.

    A 64b CPU like the Allwinner A64 with a 3GB DRAM limit is fairly pointless except for marketing purposes.

  45. Jon Smirl
    February 28th, 2016 at 22:28 | #45

    BTW – ARM is chasing 64b to get large address spaces (like 128GB of memory or more) so that there is room for many virtual machines. This is all about ARM64 on the server, not the desktop.

  46. Harley
    February 28th, 2016 at 23:47 | #46

    I too want to know if it supports hardware video decoding of HEVC (H.265) and VP9? Both are royaltee free so should be fine to use if only the hardware would support it.

    Don’t think it really deserves to be called Raspberry Pi “3” unless it the CPU is 64-bit and it supports at least hardware decoding of 1080p HEVC videos, with VP9 being a bonus.

  47. Anonymous
    February 29th, 2016 at 00:16 | #47

    Why when the latest firmware updates allow it to run at up to 600MHz with complete stability on a Pi2B? The same is likely to be true of the Pi3B unless they’ve downgraded the RAM.

  48. Jon Smirl
    February 29th, 2016 at 00:25 | #48


    h.265 is not royalty free. In fact the fight over excessive royalties is what is holding it up from deployment.

  49. No TA
    February 29th, 2016 at 00:43 | #49

    Good job you are not posting about this on The RaspberryPi forum. The posts about it get deleted by the heavy handed who answer to no one.

  50. JM
    February 29th, 2016 at 00:47 | #50

    @Jon Smirl
    Am64 is not nearly as wasteful x86-64 and there are are many performance advantages in using it, even in platforms with 2gb or less RAM.

  51. Slackstick
    February 29th, 2016 at 01:05 | #51

    @Jon Smirl

    For ARM, just like X86 but unlike MIPS and PowerPC, 64 bit is not pointless. It effectively is a complete new instruction set. ARM32 is mediocre. ARM64 is a very well instruction set with more than doubled amount of registers. Whether your pointers are 32 or 64 bit is up to you.

    Nice to see RPi moving to ARM64 that early. However, I want more performance than Cortex A35, 4GB memory and faster IO.

  52. Curmudgeon
    February 29th, 2016 at 02:09 | #52

    Is it possible that RasPi 3 will use Cortex A32? Heat dissipation for Raspberry Pi is a real challenge because the provision for HAT boards precludes use of a substantial heatsink on the SoC. In such a constrained situation Cortex A32 features offer intriguing possibilities.

  53. No Ta
    February 29th, 2016 at 02:12 | #53


    Maybe manufacturers are hoping low power use and small memory will keep Windows and the big players out of the market?

  54. tkaiser
    February 29th, 2016 at 02:22 | #54

    They mentioned they ‘improved’ DC-IN for up to 2.4A so better don’t expect less consumption and lower temperatures 😉

  55. Jon Smirl
    February 29th, 2016 at 02:23 | #55


    Totally bogus comparison….

    A64 toolbox exe from Android 5.1 – 255,280
    RK3128 toolbox exe from Android 5.1 – 150,836
    So same source code, 70% bigger.

    But this is just a proxy comparison, you need to do a lot more work to really compare.

    PS. even though things get bigger on 64b, they don’t necessarily get any slower. Sometimes they get faster due to more and longer registers.

  56. Slackstick
    February 29th, 2016 at 03:25 | #56


    Possible? Yes. I don’t know. However, I would not expect too much from ARM marketing. I would prefer a 64 bit ARM processor without 32 bit legacy instead of Cortex A32.

  57. Slackstick
    February 29th, 2016 at 03:29 | #57

    @Jon Smirl

    Did you compile the code? Even if Thumb was not used, who cares about 100KB? Of course they get faster. This is because of the new instruction set.

  58. Nz1
    February 29th, 2016 at 03:40 | #58

    If the operating system decides that its running out of ram and decides to page out part of an app to the sdcard then I imagine that the 64bit board will seem to die a lot faster then the 32bit card, if both boards have the same amount of ram.
    I like the idea of a better instruction set and more registers though. If only ram was less expensive then we might really benefit from 64bit single board computers.

  59. Slackstick
    February 29th, 2016 at 03:49 | #59


    For paging of code, the linux kernel does not write the code to the swap file as it re-uses the code still in the executable.

    Nonetheless, RAM is damned cheap. If they only would solder more of it on the PCB.

  60. Nz1
    February 29th, 2016 at 04:02 | #60

    So what happens if there still isn’t enough ram and all the data has been swapped out. Does the OS think, I tried my best and crash anyway? Thats what OS’s used to do, a long time ago, but then they fixed them.

    Compared to flash, ram is very expensive. I’m not sure why this is given that they use similar technology. I suspect it has something to do with marketing, and what they think the market can bear.

  61. Jon Smirl
    February 29th, 2016 at 04:17 | #61

    I compiled full Android builds for both CPUs. These files are not using thumb. This is the 32b ARM instruction set vs the 64b one.

    libcrypto.so RK3128 1,052,920
    libcrypto.so A64 1,673,400

    60% larger. Every code file i looked at follows this pattern.
    You see the same thing on 32/64b x86 systems.

    Note that the Android image is not 60% larger, a lot of Android is not code or written in Java. Those parts did not change size.

  62. Slackstick
    February 29th, 2016 at 04:17 | #62


    A good OS will never crash voluntarily ;-). It doesn’t give the application the requested RAM and the application should handle this. Worst case, the OS quits the application.

    Besides using multi bit cells, I suppose flash is much cheaper because it is much slower. I didn’t hear about excessive earnings of RAM manufacturers for a long time.

  63. TLS
    February 29th, 2016 at 04:26 | #63

    I’d hazard a guess that this is the first Cortex-A35 (not A53) SoC to launch. It would make sense from a cost perspective and the target market.

  64. February 29th, 2016 at 04:56 | #64

    Cortex-A53 confirmed in official datasheet. https://www.dropbox.com/s/66u2mvkuqnkec40/0900766b814ba692.pdf?dl=1

    Now to eat my hat..

  65. Stephen
    February 29th, 2016 at 05:31 | #65

    It still uses LPDDR2 DRAM, and uses more power probably because Broadcom is still using the same 40 nm process for the BCM2837 that it used for previous processors.

  66. Nz1
    February 29th, 2016 at 05:39 | #66

    I think worstcase everything should keep working but the system should gracefully degrade by using swapspace.
    Apple may have decided that its better not to use flash as swapspace because they think its too slow or unreliable, or maybe they want their users to spend dollars and buy another device with more ram, but an OS designed for real work should not be designed this way.

  67. eugene28
    February 29th, 2016 at 06:06 | #67

    @Peter Bauer
    How did you do that? No listing of it on the website.

  68. February 29th, 2016 at 06:07 | #68

    It’s carrot+stick problem.

    If developers can go on freely with almost endless swap and their apps keep on working even if the usability has gone to hell (I’m assuming you’ve experienced systems where swap is being used – it’s not a fun experience) they will never optimise anything – “it still works!”.

    On the other hand if the OS is killing your app because you’ve been careless with it’s resources then it instantly becomes a major issue to be addressed.

  69. Nz1
    February 29th, 2016 at 07:25 | #69

    I am actually using an ipad at the moment where I have to continually select Desktop view, even though I have selected it previously, because the cookies or whatever are being continually purged because the OS is continually telling Safari to release memory.
    My tabs have to keep on being refreshed because for some reason the OS is running out of memory.
    In practise telling the app to release memory seems to result in the user getting fustrated and little memory actually being released.
    When I first got the Ipad it worked flawlessly. Now with all the OS and app updates it is fustrating, although you learn to live with it, just like users back in the good old days used to live with slow mini computers that used to run on megabytes of ram.
    I would have thought at least Safari being able to store images on flash if the system was running low on ram would be a good comprimise.
    What has happened to QA?
    Maybe the solution is for the kernel developers to insist on everyone except them useing managed code, like Java.
    By the way when I was at University, many years ago, I was taught that languages like C were designed for writing operating systems. Everyone else should use a 3GL like Pascal etc because it was faster to code with less bugs. Now if only everyone had followed this wisdom we wouldn’t be getting programs with excessive malloc code and everything would work properly.

  70. February 29th, 2016 at 07:40 | #70

    “Request Desktop View” is a one shot temporary action, it’s does that by design – nothing to do with memory purging cookies or anything, it just changes the user agent anyway so nothing more than a flag to keep in memory.

    I do wish the CNX site itself was better designed so we wouldn’t need to use that kludge.

  71. Nz1
    February 29th, 2016 at 10:17 | #71

    It should keep the flag when navigating in the cnx-software domain. If it loses the flag while the browser is still navigating in the domain then that means Safari is wiping out the page variables when it shouldn’t be.
    Its only when the browser navigates outside the domain that the temp flag gets lost because the new page does not know anything about the cnx-software page software or its variables.

  72. Gabe
    February 29th, 2016 at 13:23 | #72

    You can buy it now from RS components, I think only UK customers can buy it from this site:

  73. February 29th, 2016 at 16:34 | #73

    I like the new version of the Raspberry Pi. But i think there is more to do to complete the user whises like sata and 1 GBit ethernet.

  74. April 7th, 2016 at 20:31 | #75

    Ive just open RPI3 schematics, and most parts have been removed 😮
    They just show the net to connectors. and GPIO pull up to BCM2837.

  1. No trackbacks yet.