Home > Broadcom BCMxxxx, Debian, Hardware, Linux, Windows 10 > Raspberry Pi 3 Board is Powered by Broadcom BCM2837 Cortex A53 Processor, Sells for $35

Raspberry Pi 3 Board is Powered by Broadcom BCM2837 Cortex A53 Processor, Sells for $35

February 29th, 2016 Leave a comment Go to comments

Raspberry Pi 3 board was first found on the FCC website, and thanks to various other leaks we had a pretty good idea of the board specifications including a Broadcom 64-bit ARM processor coupled with 1GB RAM, WiFi and Bluetooth, as well as basically the same features and ports as Raspberry Pi 2 Model B. But with the fourth anniversary of the Raspberry Pi Model 1 board, Raspberry Pi 3 has now officially been launched, and you can now purchase the board for $35.

Raspberry Pi 3 Board Description (Click to Enlarge)

Raspberry Pi 3 Board Description (Click to Enlarge)

Raspberry Pi 3 specifications:

  • SoC – Broadcom BCM2837 64bit ARMv8 quad core Cortex A53 processor @ 1.2GHz with dual core VideoCore IV GPU @ 400 MHz supporting OpenGL ES 2.0, hardware-accelerated OpenVG, and 1080p30 H.264 high-profile decode. Capable of 1Gpixel/s, 1.5Gtexel/s or 24GFLOPs with texture filtering and DMA infrastructure
  • System Memory – 1GB LPDDR2
  • Storage – micro SD slot
  • Video & Audio Output – HDMI 1.4 and 4-pole stereo audio and composite video port
  • Connectivity – 10/100M Ethernet, WiFi 802.11 b/g/n up to 150Mbps and Bluetooth 4.1 LE (BCM43438 module)
  • USB – 4x USB 2.0 host ports (with better power management, allowing higher power peripherals), 1x micro USB port for power
  • Expansion
    • 40-pin GPIO header
    • MIPI DSI for Raspberry Pi touch screen display
    • MIPI CSI for Raspberry Pi camera
  • Power Supply – 5V up to 2.4A via micro USB port
  • Dimensions – 85 x 56 x 17 mm

So the specifications were more or less as expected from the leaked information we’ve received before the official release, and people hoping for 4K or H.265 video decoding will be disappointed. The new processor is said to be 10 times faster than BCM2835 processor found in the first Raspberry Pi Model B board, and it’s likely it can handle 1080p H.264 @ 60 fps using software decoding. The VideoCore IV GPU’s subsystem is now clocked at 400MHz and the 3D core at 300MHz against 250MHz for previous “Raspberry Pi processors”.

Since they’ve basically kept the same features as Raspberry Pi 2, beside changing the Cortex A7 cores to 64-bit Cortex A53 ones, and adding built-in WiFi and Bluetooth via a BCM43438 module, firmware support is basically the same with various Linux distributions – Raspbian being the recommended distro – and Windows 10 IoT.

You can now buy Raspberry Pi 3 on RS components for £26.75 (~$37) with over 30,000 boards in stocks right now, as well as Element14, Pimoroni and ThePiHut. A Raspberry Pi 3 Model A without Ethernet, and BCM2837-based Compute Module 3 are also planned for later this year.

  1. Jeroen
    February 29th, 2016 at 14:03 | #1

    Would love to see a benschmark vs the AmLogic S905.

  2. Koxx
    February 29th, 2016 at 14:13 | #2

    HUGE disappointment… no h265 🙁

  3. hwti
    February 29th, 2016 at 14:28 | #3

    This is an ARMv8 CPU, not ARMv7.
    Since it’s a Cortex A53, and the GPU frequency increases from 250 MHz to 400 MHz, I think it’s now a 28nm chip instead of the original 40nm.
    I wonder why they didn’t increase the RAM frequency.

  4. February 29th, 2016 at 14:29 | #4

    @Jeroen
    Amlogic S905 should still be considerable faster simply because of the higher clock speed (2.0 GHz vs 1.2 GHz), so about 67% faster. Eben Upton said they did some custom optimizations, so the difference might be lower.

    I’m not sure about the GPU, but the VPU in Amlogic S905 is also much better since it supports 4K video, and H.265. maybe I should do a Raspberry Pi 3 vs ODROID-C2 comparison one of these days…

  5. February 29th, 2016 at 14:37 | #5

    @hwti
    Sorry, copied past specs from RS components or other distributor’s document, and I missed that mistake. Corrected.

  6. February 29th, 2016 at 14:46 | #6

    BCM43438 combo chip is used instead of BCM43143 for RPi 3 model B.

  7. tkaiser
    February 29th, 2016 at 14:52 | #7

    Since they don’t provide new NOOBS/Raspbian versions, booting is still proprietary (loading BLOBs on the VideoCore first) and they want their users to run ARMv6 ‘optimized’ code on ARMv8 with a 32-bit kernel. What’s this 64-bit thing about?

    The most interesting part is the new 2.5A PSU for other SBC users that suffer from undervoltage due to crappy USB cables and the crappy Micro USB connector used for DC-IN (especially Pine64 and Banana Pi M3)

  8. February 29th, 2016 at 15:14 | #8

    Raspberry Pi 3 Benchmarks: https://www.raspberrypi.org/magpi/raspberry-pi-3-specs-benchmarks

    Drystone-2 is not as different: 2624 for C2 vs 2458 for Rpi3

  9. February 29th, 2016 at 15:19 | #9

    @cnxsoft
    But Power consumption of raspberry Pi 3 is quite higher: 0.31A (idle) and 0.58 A (under load) against 0.26 and 0.42A for Raspberry Pi 2.

  10. tkaiser
    February 29th, 2016 at 15:39 | #10

    @cnxsoft
    These benchmarks are the usual joke targeted at clueless people (you measure compiler settings and optimisations and not hardware and on modern SMP hardware with thermal throttling active you should simply forget ‘benchmarks’ that were created 30-40 years ago).

    But it’s good they chose sysbench. When I used the usual armhf sysbench binary on a Pine64+ it finished already in less time than RPi3, when I compile it from source for ARMv8 then it finishs in less than 4 seconds: (Obviously wrong) conclusion: the Pine64 is 12 times faster than RPi3. At least it’s a good indication how moronic it is to stay with code ‘optimised’ for ARMv6 on ARMv8 like the RPi Foundation does now 😉

  11. memeka
    February 29th, 2016 at 15:57 | #11

    @cnxsoft:
    “with dual core VideoCore IV GPU @ 400MHz”

    I think it’s single core, like the older pis.
    also, 24GFlops is at 250Mhz, now it should be a bit better…

  12. Sander
    February 29th, 2016 at 16:01 | #12

    For people in the Netherlands: Raspi3 available for € 42,95 on https://www.kiwi-electronics.nl/raspberry-pi-3-model-b

  13. memeka
    February 29th, 2016 at 16:07 | #13

    also, those benchmarks don’t have any GPU results, but looking at the raw numbers (for those interested in retro arcade machines):

    videocore4 @ 250Mhz: 24GFlops
    videocore4 @ 400Mhz: ??? (~38 GFlops?)
    mali450mp2 @ 500Mhz (c1): 30GFlops
    mali450mp3 @ 750Mhz (c2): 56GFlops
    malit628mp6 @ 533MHz (xu4): 102GFlops

    i think the rpi3 should handle now running some psp games w/o frameskipping…
    the problem on both rpi3 and c2 is that emulators are not upgraded for aarch64, so it won’t work on cortex a53 for a while…

  14. February 29th, 2016 at 16:17 | #14
  15. blu
    February 29th, 2016 at 16:25 | #15

    I can’t believe what I just read:

    While the 64-bit capability means that 64-bit operating systems could come to the Pi, there are no specific plans yet, Upton said. “We’re going to wait until someone can demonstrate a concrete benefit to going to 64-bit before we make that our standard,” he said.

    It’s like Upton has not seen the AArch64 ISA, neither the benefits to the compiled code that ISA brings. It takes a couple of hours looking at the generated code (or measuring the performance, if looking at AArch64 is not an option), to see what benefits that ISA brings. Particularly in the ASIMD (new NEON) where the difference in the compiled code is staggering.

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

    @blu
    Couldn’t agree more. Eben Upton would be surprised how fast sysbench runs (on the RPi3 in less than 5 seconds) when making use of AArch64/ARMv8. Then he would be able to advertise the RPi3 being ‘over 100 times’ faster than the 1st Pi and maybe then he gets the idea 😉

    They use ARMv8 cores in ARMv7 mode and run software for ARMv6 on it. Kind of fascinating…

  17. February 29th, 2016 at 16:46 | #17

    @tkaiser
    @blu
    ODROID-C2 will run 64-bit code, but they warn that:

    ARM 64bit is a very new platform and some system specific Linux softwares are not working stably at this moment.
    So there might be the compatibility issues frequently and we may need longer time to fix the issues.

    It’s also somewhat related to the fact that they use Ubuntu 16.04, which has yet to be released…

    I’ve also noticed most of the ARMv8 Android devices I’ve tested so far are running a 64-bit Linux kernel with a 32-bit Android.

  18. blu
    February 29th, 2016 at 17:01 | #18

    @cnxsoft
    Having sw compatibility issues is one thing, but ‘waiting to be shown the potential benefits’ is frankly ridiculous.

    On the subject of AArch64 sw compatibility in Ubuntu – one can always (a) use a cloud AArch64 provider, or (b) use QEMU, and try the different Ubuntu images to see if this or that package is ok.

  19. Jeroen
    February 29th, 2016 at 18:14 | #19

    cnxsoft :
    @Jeroen
    Amlogic S905 should still be considerable faster simply because of the higher clock speed (2.0 GHz vs 1.2 GHz), so about 67% faster. Eben Upton said they did some custom optimizations, so the difference might be lower.
    I’m not sure about the GPU, but the VPU in Amlogic S905 is also much better since it supports 4K video, and H.265. maybe I should do a Raspberry Pi 3 vs ODROID-C2 comparison one of these days…

    Would be great, considering to buy a C2.

  20. memeka
    February 29th, 2016 at 19:12 | #20

    there are already 32bit images for C2, and seems like rpi3 images are also 32bit.
    the official c2 image however is 64bit, and seems that some things won’t work… eg. chrome

  21. tkaiser
    February 29th, 2016 at 19:40 | #21

    I checked again settings and when I try the usual ‘sysbench’ run the RPi Foundation uses then on the Pine64+ execution times is 15 times less compared to the results published for RPi 3: http://forum.armbian.com/index.php/topic/751-rfc-support-cortex-a53arm64/?p=5731

    So if they would start to switch the Raspbian base from the ARMv6 code base to arm64 they could promote the RPi 3 being even 1500 times faster than the 1st RPis! But they would still lose against ODROID-C2 since using meaningless benchmarks like sysbench with inappropriate settings the S905 will show superiour performance… until throttling jumps in 😉

  22. February 29th, 2016 at 20:10 | #22

    @blu
    @tkaiser
    OK so I can see sysbench is much faster using code compiled for ARMv8 compared to ARMv7. I guess it might be because of the new Aarch32/Aarch64 instructions available in ARMv8 might help, or could there be other reasons? A 15x speed up seem a little too much, especially I assume (wrongly?) sysbench is mostly doing some integer and/or floating point operations.

  23. tkaiser
    February 29th, 2016 at 20:51 | #23

    @cnxsoft
    IMO, these are two different things. The 1st is that approx. 101% of all passive benchmarking is wrong more or less — a good starting point for that:http://www.brendangregg.com/activebenchmarking.html (_if_ my use case is calculating prime numbers then I will see an improvement of factor 15 when I use ARMv8 instead of ARMv6 code on Cortex-A53 — if that’s not the case then this benchmark might be simply misleading _now_ and all results from now and then should be dropped)

    Then moving the code base to ARMv8 on ARMv8 is a no-brainer regardless of questionable benchmarks. IIRC I saw slides from ARM where they achieved ~50% better performance by making use of the new Aarch64 ISA and recompiling code. And instead of ‘waiting to be shown the potential benefits’ they could’ve already finished bringing the BCM2837 up in Aarch64 instead of Aarch32 state and switching Raspbian’s base to arm64 (especially given the speed of improvements a couple of volunteers currently make in their spare time for the A64 for example)

  24. blu
    February 29th, 2016 at 20:58 | #24

    @cnxsoft
    Well, for one, compiler’s autovectorization actually works with aarch64 NEON, whereas in armv7 you had mostly to rely on manual vectorization via inline asm. Another big win is the twice-larger GPR & FPR files (when it comes to fp64: D16 -> D32), largely reducing register pressure in compiled (and not only) code. Last but not least, recent compilers have been more focused on AArch64, where they could produce better code vs armv7 not so much because of hw resource discrepancies, but because more man-effort went into AArch64 backends (and the arch provides a bunch of small tweaks that make compiler writer’s lives easier).

    To sum it up, one can observe a significant speedup from armv7 to AArch64 for both objective (i.e. larger hw resources) and subjective (i.e. greater man-effort) reasons.

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

    @tkaiser
    Would you remember the ARM slides you’ve seen? I can only see http://www.arm.com/files/event/C2_64-bit_Android_Open_Source_Project_Applications_and_Advantages.pdf, but they are mostly showing improvements in benchmarks (Antutu, Quadrant, Linkpack), and it ranges between 15 to 25+%.

  26. tkaiser
    February 29th, 2016 at 21:58 | #26

    @cnxsoft
    You were right, when comparing 32-bit vs. 64-bit it’s ~20%: http://www.anandtech.com/show/7995/arm-shares-updated-cortex-a53a57-performance-expectations (but we should keep in mind that regarding RPi we’re not talking about optimised software tested both with Aarch32 and Aarch64 but instead pretty unoptimised 32-bit ARMv6 vs. 64-bit ARMv8 code)

    But blu’s thoughts/reasons are more important than this ‘benchmarking gone wrong’ crap (out of curiosity I let Unixbench run on the Pine64+ http://kaiser-edv.de/tmp/vYq9cG/UnixBench_on_Pine64.txt — Dhrystone 2 = 6084893.6? And the SoC didn’t even heat up, this is all single threaded stuff useful maybe decades ago)

  27. paul
    March 1st, 2016 at 05:35 | #27

    @cnxsoft
    “But Power consumption of raspberry Pi 3 is quite higher: 0.31A (idle) vs 0.58 A ”
    Not according to Christopher Stanton’s Benchmark on Element14 pointed to by liliputing. His measurements show the difference in default idle power between a P2 and Pi3 is 200mA v 220mA, i.e only a 20mA increase, which he thinks may be due to the BCM43438 Wifi/BT chip. I cannot find a datasheet for the BCM43438. However, as he measured each at their default clockspeeds, and the A53 is clocked at 1.2GHz rather then the 900MHz of the A7, it would be interesting to measure idle consumption of Pi3 using the same SoC clockspeeds (900MHz CPU, 250MHz GPU etc) as the Pi2. Hope you can do a comparative review of Pi2, Pi3, ODROI-C2 in due course.

  28. mdel
    March 1st, 2016 at 20:42 | #28

    does anyone know if there are been changes (improvements) in the h264 video encoder or camera interface on the rpi3 ?

    i’ve used some pi b+ with camera modules quite extensively and i must say i was not impressed by the quality of the h264 encoder and/or processing (scaling/binning especially) of the 5Mpix sensor.

    I would also be quite disappointed if power draw was significantly higher, as most of my rpi projects are battery powered, but i guess the wifi/BT module could be disabled or disconnected.

    And i must say that no 4k/h265 will start to make the rpi3, compared to the competition, look a lot like the arduino compared to the rpi, all things considered. That said h265 content is still marginal and i would assume that feature will be included in the rpi4 next year.

  29. Matt
    March 3rd, 2016 at 00:00 | #29

    @mdel I agree with the last paragraph, but as far as 4k-2k goes it’s not that marginal. I see RPi3 as something like a ZX Spectrum 3+ right now. The only thing that could save it is raw horsepower. I’d really wish to be wrong, but with no Videocore V on the horizon we’re getting to a dead end GPU-wise.

  30. mdel
    March 3rd, 2016 at 14:58 | #30

    @cnxsoft
    Is the lack of 4k/hevc Broadcom’s fault for not providing it, or do they already have 4k/hevc socs and it was a real rpi foundation choice to skip that ?

    @Matt
    well 2k/4k/hevc (content) is very marginal in my multimedia environment, which is of what my “non computer savy” peers have access to at the moment and probably will for the 1-2 years to come, yeah they’ll buy 4k TV sets as they are told to, then what..

    Anyways, i have mixed feelings about rpi future if they don’t intend to keep up performance wise on the gpu (openvz) and video (kodi) sides.

    It is still a full featured board, but no 4k/h265 will make many people look for alternative boards for multimedia purposes, the same comment can be made for people who want android compatible devices, or more powerful arm chips for openvz projects.

    Then when you start to play with gpios you very quickly realize that you can turn to much cheaper devices, like arduino or rpi zero. I would personally have replaced all my b+ with zero but most unfortunately the zero doesn’t have the CSI port.

    The real question is, amongst rpi users, what’s the number of them that actually use it for “computer stuff” as the rpi foundation promotes its product ?
    I very highly doubt that the million+ of boards sold, were to students, “makers”, or people wanting to learn about computer..

    Is wireless supposed to place the rpi on the IoT market ? Considering its “high” price and the rage going on with ESP8266 boards, i’m not seeing that happening.
    Maybe they can produce a zero+ with BT/wifi at the same $5 price, that would probably be more exiting than this rpi3..

  31. March 3rd, 2016 at 20:40 | #31

    @mdel
    Broadcom is the leader in the STB SoC market, so they’ve had chips capable of decoding H.265 @ 4K resolution for a couple of years. But the Raspberry Pi foundation wanted something software compatible so they designed a new SoC with most of the same blocks as found in BCM2835 and BCM2836.

  1. No trackbacks yet.