Look inside the Raspberry Pi Zero 2 W and the RP3A0-AU

Today, Raspberry Pi released their new Zero 2 W, and it includes a new Raspberry Pi-branded chip, labeled RP3A0-AU.

I was able to get early access to the Zero 2, and I have a full review of the device on my YouTube channel, but I wanted to share more of the X-ray images I took of the device to reveal its inner workings, and because I just think they look cool. Also, I paid a bit of money to get these pictures, so might as well share!

First, here's what the Zero 2 W looks like in person:

Raspberry Pi Zero 2 W

And here's what it looks like via X-ray:

Raspberry Pi Zero 2 W - X-ray vision

You might already see a few of the easter eggs hidden inside, but let's first get the basics out of the way. This board has the exact same physical layout as the earlier Pi Zero W, with the same I/O, meaning it will fit in almost every accessory and project designed for earlier Pi Zero models.

For I/O, it features:

  • 1x mini CSI connector on edge for Pi Camera modules
  • 1x microSD card reader for boot volumes
  • 1x micro USB power input
  • 1x micro USB data port
  • 1x mini HDMI display port
  • 40-pin GPIO (following standard Pi layout)

But looking more closely at the X-ray image reveals what's inside the new Pi chip:

Xray picture of side of Pi Zero 2 W SoC chip with RAM package on top RP3A0-AU

You can distinctly see two sets of bond wires—in this case, gold bond wires, as indicated by the -AU chip suffix—with one leading to the 512MB LPDDR2 RAM on top, and the other leading to the BCM2710A1 clocked at 1 GHz on the bottom.

So this is not custom silicon, but it is a custom 'package'. Older Pi Zero models (and some of the older Pi A/B models) used a package-on-package layout, but the BCM2710 used here didn't come in a variety that was stackable. So Raspberry Pi decided to make their own, and put it all inside one easier-to-mass-produce chip.

But I was looking through more angles via digital X-ray when something else caught my eye:

Raspberry Pi Zero 2 W BGA Xray pattern with mini Raspberry Pi Logo

Do you see that little pattern in the middle of the BGA ('Ball Grid Array') on the main chip? Does it remind you of anything? How about we zoom and enhance:

Raspberry Pi Logo in BGA ballout on Pi Zero 2 W

And there it is! I stuck a transparent Pi logo on there in case it's still hard to see. I love seeing little design details like this, since it reminds me of the signatures inside the Macintosh case—a little mark of pride from the hardware designer that also shows a spirit of playfulness... and in a place where vanishingly few people will ever notice!

I had to know more, so I asked Gordon Hollingworth about the design, and he referred me to Simon Martin, who was principle designer of this chip. He was happy to see someone noticed, and had a bit to say:

The BGA ballout is just a bit of fun. The balls on the outside of the package contain the I/O signals and have to be carefully placed. The balls in the middle are just power and ground (and help with cooling) so can be placed in any arrangement.

I also asked a bit more about the chip design since, well, he designed it! And he mentioned that the SoC and DRAM have a silicon spacer to make sure the bond wires aren't crushed during manufacturing. And he also mentioned why they chose gold bond wires:

It's a busy looking thing if viewed under X-Ray. Over 800 gold bond wires [...] We got a bit scared of using cheaper copper wires in the package and decided on the gold version to ensure a long life.

So there you have it! I also wanted to take a peek under the WiFi/Bluetooth module cover, to see what's inside, and it's very similar to the older board, just encased inside a metal shield:

Raspberry Pi Zero 2 W WiFi Bluetooth undercover X-ray shot

I'll get more into this next week, but the actual chip used here is the SYN43436, made by Synaptics. It's very close to the BCM43438 used in the 3 model B and Zero W, but it does require dedicated firmware, and that threw me for a loop while working on a RetroPie build for the Zero 2 W!

Anyways, that about sums up the 'inside look' at the Zero 2 W—please check out my YouTube review of the Raspberry Pi Zero 2 W for more juicy design details.


To help those who don't enjoy sitting through videos, I'm also posting the performance benchmarks here:

x264 Encode phoronix benchmark results on Pi Zero 2 W

I ran all these benchmarks using my pi-general-benchmark script, and this first one was interesting—due to the fact the Pi Zero W and Zero 2 W have 512 MB of RAM, it was hard to even get the benchmark to complete. The OOM (Out Of Memory) Killer was ruthless in killing the runs until I gave the Pi at least 512 MB of swap space on the slow microSD storage.

It's not showing a ton of speed, but another thing to note is the Pi Zero 2 can take an overclock of 1.2 or even 1.4 GHz with adequate cooling. I get more into thermals and efficiency in my video, but moving on to the next benchmark, the following become apparent:

  • The Pi Zero 2 W is 2x faster at base clock on 32-bit Pi OS.
  • The Pi Zero 2 W can finally run 64-bit Pi OS.
  • The Pi Zero 2 W can be 3-4x faster (or more!) running 64-bit Pi OS with a slight overclock.

Here's the result of an MP3 encode test:

MP3 Encoding Phoronix test benchmark results for Pi Zero 2 W

And finally, phpbench:

phpbench phoronix benchmark results on Pi Zero 2 W

You can expect everything to run at least twice as fast, sometimes 3-4x faster, on the Pi Zero 2 W with it's quad-core A53 chip. But RAM is definitely a limiting factor for many uses.

Two other things I tested were networking performance—since the upgraded CPU can make a difference there—and power consumption:

WiFi and Wired LAN networking performance on Pi Zero 2 W

WiFi is about twice as fast, and Wired LAN performance with a Gigabit USB Ethernet adapter is about 25% faster. I should note that it still pales in comparison to the Pi 4, which doubles WiFi performance again, and has built-in 1 Gbps Ethernet!

Finally, here's power consumption as measured by a PowerJive USB power meter.

Pi Zero 2 W Power Consumption Benchmarks

If you turn off almost everything on the Pi Zero to reduce power consumption, you can get the Zero 2 W down to about 100 mA, or 0.52W. The original Zero W could get down to about 80 mA, or 0.42W.

Back side pads

On the back of the Pi Zero 2 W, there are a number of unlabeled pads that can be tapped into for things like composite video output or USB via pogo pins. Unlike the rest of the board's physical layout, the layout of these pads has changed a bit, so some gear that relied on those pads being in a specific location will need to be changed.

Here's a simple image showing the pad locations with the Zero 2 W on top, and the Zero W on bottom:

Pins and pads on bottom of Pi Zero 2 W in different locations than the pads on the Pi Zero W at bottom


The Zero 2 W is a nice upgrade over the Zero W, and makes some uses—like retro gaming or light duty tasks—a lot less painful. It's still no performance champ compared to the Pi 4, but it comes in with good features for a still-low price, and I can imagine it'll be hard to find one in stock for some time!

I'll be back next week with details on how I integrated the Pi Zero 2 W in a Null 2 RetroPie gaming handheld build, so be sure to subscribe on YouTube and subscribe to this blog's RSS feed!

And if you haven't yet, go watch the full YouTube review of the Raspberry Pi Zero 2 W.


Apparently this isn't the first SiP (System in Package) Raspberry Pi produced—there was another back in 2011, according to their announcement post:

But there’s another way to avoid discrete SDRAM, and if you’ve been following Raspberry Pi since the start, you’ve met it before. Back in the day, BCM2835 had a slightly evil twin, BCM2763, which integrated a 128MB SDRAM die directly into the package along with the SoC die; this arrangement is known as a system-in-package (SiP). BCM2763 was intended for use as a graphics coprocessor for mobile phones, and powered the original Raspberry Pi prototype we demoed back in 2011.

That was a chip produced at Broadcom, not Raspberry Pi. Although funnily enough, Simon, who designed the BCM2763 package when he worked at Broadcom, now works at Raspberry Pi and also designed RP3A0.

Someone on Hacker News asked if you can USB boot now, since the Pi 3 B supports it. Unfortunately, my attempts have been fruitless. I tried the following procedure (which works on the 3B), but it didn't work on the Zero 2:

  1. Add program_usb_boot_mode=1 to /boot/config.txt
  2. Reboot the Pi
  3. Verify vcgencmd otp_dump | grep 17: outputs 17:3020000a
  4. Shut down the Pi
  5. Flash Pi OS to a USB flash drive, plug it in, unplug the microSD card, and boot

The Pi Zero seems to just sit there (no HDMI output, no LED activity) if you don't have a bootable microSD card inserted.

I've also posted this question on the Pi Forums: USB boot on the Pi Zero 2 W?

Interesting -- not something I've had the time to try yet; the original Zero (and theoretically the A-series, though I never got that working) could also be booted from USB *device* mode (i.e. plugged into a PC with the Zero reporting itself as a device). Have you given that a spin yet?

According to Jeff's tests, yes! And it looks like it will work, even without negotiation! (In case anyone reading this didn't already know, part of the USB spec is to provide only 500mA to a 'dumb' device. If you want the full 3A or whatever it is that the controller supports, then your device has to communicate with the host.)
0.5A * 5v = 2.5W out of the upstream port, which is more than enough to power the 2.12W of the Zero 2 that Jeff has measured.

Someone mentioned, somewhere, a theory that explains Trading's ridiculous 2.5A 'power requirement': perhaps this is to get rid of the stock of 2.5A-capable wall warts as sales with the new board. (Found it, the comments are on this post: https://www.cnx-software.com/2021/10/28/raspberry-pi-zero-2-w-and-zero-…)

Anyway, I'm glad to know that this board will only pull 2.12W - I was considering leaving it out of my latest design because of power consumption.

Of course the big question is: Will it fit (and work!) in the Retroflag GPI case?

Looks like I have all of the answers today :)
I'm not familiar with that case, but if the previous Pi Zero will fit, this one should too. (I believe the footprint and pinouts are identical.) One thing to note, however, is that the chips have moved around. So any case that makes contact with any chips, passives, ICs, or the board itself could be affected. As long as it's not touching the board's surface too closely, for cooling or otherwise, it should be okay.

Okay, having watched a very uncut teardown of that case, it looks like the second edition will fit in there with no issues! Hooray!

Apparently all these images came from the pi foundation, not you. Pi foundation announced this with the pics of the BGA raspberry etc.
Why claim you are the one who "discovered" it?

All the images in this blog post were images I acquired—at a bit of a personal expense... machine time on $500K x-ray/CT imaging machines is not free! I was just pleased to find that hidden icon while I was investigating the chip via x-ray imagery, and I wanted to share.

It's within the Pi Foundation's rights to also reveal the same thing in their own blog post ;)

I've been looking at the 64-bit version of PiOS but all the information I've found points to 'it's not stable/it's in beta'.

Have you experienced any serious instability with it so far?

It would be nice to be able to roll it out now with some sense of stability (especially on headless devices in remote locations) for future-proofing reasons and be able to dist-upgrade as it matures.

The main things that are not yet stable are some Pi-specific interfaces, like the CSI camera connector and cameras, or some displays via DSI.

Honestly for all my headless servers, I've only been running 64-bit Pi OS for the past year now with no issues whatsoever.

There is a lite version of the 64-bit OS image.
I can't post the link because it's getting flagged as spam and won't post.


You mentioned the camera interface not being 'stable' ... in my case (just received a Zero2 starter kit) the camera interface doesn't show at all in Bullseye Raspi-config and reinstalling with Buster did not solve that. (although I did so a sudo apt update && sudo apt upgrade after installing Bullseye). Did you come across any other mentioning of the camera interface failing ?

Jeff, have you ever tried 'stress-ng --cpu 4 --cpu-method matrixprod'? Should be a little bit more stressful.

Anyway, even if CPU cores are a bit more utilised and the VideoCore as well I would believe the maximum consumption figures are still far away from the official 5V @ 2.5A 'power requirement'... any explanation for that?

I believe the official requirement has a lot of headroom—the Zero 2 W doesn't need 2.5A, but the power supply has that available since many people will use it with a 3B+ or 3B and it's better to not make it underpowered for that use case.

Well, that makes sense... to look at it from the wall wart's perspective ;)

Seriously: this board is not even remotely close to a 7.5W power requirement since it's basically a RPi 3B minus LAN914 (saving 700mW) with better DVFS and slightly faster memory access. With 1 or 2 cores disabled it will never exceed 2.5W which makes it suitable for one use case we're thinking about... powered by a PCs USB port.

BTW: when running low on memory when benchmarking... why do you add swap on SD card instead of ZRAM? Things like this might happen: https://github.com/ThomasKaiser/sbc-bench/pull/23#issuecomment-954717614

Hi Jeff,

Which 64 bit image are you using?

I've tried both of these builds from the official download site with no luck, just a hang at the rainbow splash screen

32GB Samsung Pro Endurance MicroSD, and also a 8GB SanDisk generic MicroSD have the same issue. Imaged with dd, also tried the official Raspberry Pi imager running on Ubuntu 21.10.

32-bit builds work fine. Not sure what voodoo you're doing to get it to boot!

I've been testing with raspios_lite_arm64-2021-05-28 — but at the current time (until a new one is built), it doesn't include the zero2 .dtb file that's required for a boot. Without it, you just get nothing at all... I'd post an issue on the Pi Forums and ask about it, maybe it'll entice the folks at HQ to drop a new arm64 release!

The 64 bit version had the same issue here with hanging on the rainbow screen. I got it working by starting it on a Pi 3B+ first, do all the updates and run rpi-update. After that: I put the SD card into the Zero 2 and everything seems to work fine including wireless/bluetooth on the 64 bit build now.

Hi, thanks for the tip, it worked for me as well with a fresh raspios_lite_arm64-2021-05-28 booted on a Pi 3A+, with a dist-upgrade then a rpi-update.

For science, I have tried step by step, and can confirm that as of today, rpi-update is mandatory. Unless you really are into rainbow screens :)

Hi Jeff,

as you mentioned, the 64-bit image lacks the device-tree files for the zero2. Can you elaborate or post the missing files. I have some experience in this area, but mixing the device-tree specifications from the bootable 32-bit does not get me the Pi Zero 2 W to boot the 64-bit kernel8.img.


The one I used was internal / not to be shared, unfortunately. I'd open a new thread asking for it (or a new 64-bit build) on the Pi OS forums to try to get that expedited :(

Two big reasons:

First, there are a number of workloads where 'those silly non-realistic workloads tested in Phoronix/sysbench/etc.' are actually very realistic, and in those cases (more typically, things that compress/decompress, or crunch numbers), 64-bit is going to be demonstrably faster.

Second, for me (and for many nowadays), almost every piece of software or Docker image I use, no matter how niche, has an arm64 build. Very few outside of Pi-specific software have well-maintained (or any) armv6/armv7 builds. So running on 32-bit Pi OS and being able to run the software I need to run is quite literally impossible (or nearly so, unless I want to spend my days recompiling things and fixing bugs on an unsupported setup).

I never say "everyone should go 64-bit", but I do hint that it would be nice if we could move everything to it. And in my reviews/video about the Zero 2 I did explicitly state that the RAM limitation is crippling, and thus I used 32-bit Pi OS for almost every test I did.

Thank you for the answer! Me being a 'use case first' guy do not really see the point of number crunching or Docker on something like an RPi Zero but I'm really interested in an indication that certain 'real' workloads do benefit from moving to 64-bit performance-wise

Please no 'go to the forums' since what happens mostly there is comparing old benchmark numbers (made with e.g. Jessie or Stretch AKA 'software built with GCC 4 or 6 for ARMv6') with a 64-bit distro using GCC 8 onwards on a recent firmware/ThreadX version that is responsible for faster memory access over time. And the difference caused by all of this will be sold as '64-bit performance benefits' vs. 32-bits.

The best example is 'sysbench cpu' which performs 15 times faster on the same hardware when allowed to run with ARMv8 code since there's a division instruction (the sysbench performance boost is not related to 32-bit vs. 64-bit but the compiler being allowed to generate code for ten years old ARM CPUs using their instructions instead of code for 20 years old CPUs – ARM11/ARMv6 have been announced over 20 years ago! And that's what the RPi standard userland is built for)

In case you have a good starting point for a real comparison (using same ThreadX / kernel / GCC version) I would love to be pointed to (currently in the process of reviewing an M1 Pro thingy and preparing some stuff wrt 'energy aware computing', especially with compression/decompression in mind).

The sysbench example isn't nothing, though. Being able to run a distro that's based directly on upstream Debian instead of on the fork specifically maintained for Raspberry Pi brings other benefits too, and since 99% of the world's moved on from ARMv7 and earlier, there are many packages that are either not tested or outright have bugs running on older architectures.

In the end, do I care much on a Pi with 512 MB of RAM? Not really, camera interfaces and a few other things don't even work right yet on 64-bit Pi OS releases... so it's better to stick with the 32-bit build there.

But for any of the newer Pis with 2+ GB of RAM I don't see any value in sticking on an old, less-supported architecture.

For me it's less about the performance, it's more about the compatibility.

Following GalaxyA51's advice in this thread, I confirm it works fine by booting a fresh raspios_lite_arm64-2021-05-28 in a Pi 3A+, with a dist-upgrade then a rpi-update.
Now let's get into DNS benchmarking with Pi-Hole and Cloudflared 32 vs 64 bits. (Pi Zero W vs Pi Zero 2 32 bit show very marginal improvement, not worth the upgrade).

And... GRC's DNSBench shows no real improvement running Pi-Hole and Cloudflared on 64 bit rather than 32 bit on the Pi Zero 2.
Nor is it worth upgrading from a Pi Zero W to the new Zero 2 for that use case.

Two methods:
1) the above, first a 64 OS on the RPi 3, then use it in the RPi Zero 2.
2) flash an SD card with the latest 64-bit Raspberry OS, and rename the bcm2710-rpi-3-b.dtb to bcm2710-rpi-zero-2.dtb. The bcm2710-rpi-3-b.dtb is located in /boot. Once renamed, you can insert the SD card into the RPi Zero 2 and follow the normal procedure.

Be aware there are still issues with the 64 OS running on an RPi Zero 2. For instance, Chromium, Firefox, mentionEyeOS are not working. Also, with the first method.

If you use method 1, you will find a bcm2710-rpi-zero-2.dtb and a bcm2710-rpi-zero-2-w.dtb in your boot folder. It seems the programmers have made the device tree files already. However, behind the rpi-update curtain, it is undoubtedly under construction.

Anyone knows if bad things happen if one accidentaly feeds 5V power into the microUSB port of the Pi Zero 2W? Both microUSB ports, I just did that... power and usb are next to each other, for some reason I just did not look careful when i plugged it in.

A question about the „test“ pads on the back, I’ve noticed not only the layout changed but 5v and Gnd is no longer printed on the board. Is it save to assume the left hand located pads are still usable for 5v power supply? I couldn’t find any information about them…

It turns out, they indeed have the same purpose. What's strange is that one of my zero 2 has no printings on the back while another one, which arrived just yesterday, has.

Are you sure about those Pi Zero ethernet speeds .... ?

Yes; if you use a gigabit USB 3.0 NIC, it will still get better-than-100 Mbps performance on even the oldest Pi Zero through it's USB 2.0 bus.