I've just been reading a lot of online comments on Reddit, these forums, and even on YouTube reviews about the Pi 4 and have read complaints that the RPT has repeatedly answered and yet keep getting asked. So, I've compiled a bunch of the "complaints" here, and my hope is that the RPT could tweak this post and pin it or use this post as inspiration for a blog post. I don't want to sound bitter - it's just annoying to read haters online over the most selfish of complaints.
Also, for the RPT Engineers: This took a long time to write. I am extremely thankful for your work on the Pi 4, and (other than buying one), I hope that this defense of your decisions can help me "give back" to you a little bit. Thank you very much for your work on Pi 4 (which was way beyond my reasonable expectations), and I wish you the best of luck while you work on your next project!
Without any more intro...
Why no eMMC option? The CM3 has this!
1. Cost: According to Mouser.com, cheap 32GB eMMC starts at about $22. More expensive, high quality eMMC is $44 for 32GB. That's more than the Pi 4 costs by itself, and is probably still expensive even in bulk. Even if it is offered as an option, running multiple SKUs of any product is a logistics nightmare. You'd probably have the Pi 4 1GB-RAM/No-eMMC, Pi 4 2GB-RAM/No-eMMC, Pi4 4GB-RAM/No-eMMC, Pi4 1GB-RAM/16GB-eMMC, Pi4 2GB-RAM/16GB-eMMC, Pi4 4GB-RAM/16GB-eMMC, Pi4 1GB-RAM/32GB-eMMC, Pi4 2GB-RAM/32GB-eMMC, and Pi4 4GB-RAM/32GB-eMMC. Ouch and expensive to produce, and if RPT overproduced one SKU, that could cause significant financial damages.
2. Space: There is no space on the PCB for eMMC even if RPT decided to add it. The Pi is actually a six-layer circuit, and spent over 6 months in design being ~5mm too wide because of the incredible difficulty in getting the current circuit to fit inside the Model B form factor. A brand new form factor would be necessary, but according to a recent interview, the RPT has no intention to launch a hypothetical "Model C" anytime soon. There is no way to fit an eMMC chip onto the Model B form factor without adding more layers to the PCB's 6 - which is currently very expensive.
3. Portability: One of the beauties of SD Cards is that you can develop your project on a top-of-the-line Pi 4, take the SD Card out, and plug the SD card into a power-efficient Pi Zero. You also can mass-copy an SD card onto, say, 30 cards for classrooms. Not with eMMC.
4. Wear-leveling: If someone damages an SD card due to heavy wear, it is replaceable. With eMMC (which is not necessarily more reliable than SD cards), you have a Pi 4 with bad storage. Can you imagine a Raspberry Pi wearing out over time? That's something that current Pi's don't really have a problem with. Industrial customers might not care - but students and teachers in schools will not be pleased with boards that can permanently wear out if overused. This could also lead to schools preventing students from trying certain projects for fear they would wear out the board.
5. Corruption: If an eMMC is corrupted, repairing it is difficult. Bricking a Raspberry Pi permanently is currently very difficult - just download a new SD card image, good as new, no matter what stupid thing you did (unless you overclocked to oblivion). With eMMC, you could, in fact, potentially put a Pi in a situation which might need professional Linux expertise to repair. [It may be possible to have a repair system in the boot loader, but that may or may not be possible in all situations, and costs money to develop.]
Why no eSATA? This would be great for NAS!
1. Cost: The SoC has no built-in support for eSATA, and Broadcom (as far as we are aware) has no licensable eSATA blocks for mobile chips. This means either spending easilyover a million dollars (this is not hyperbole - more like several million) to add SATA support to the SoC. The other option is to add a SATA to USB 3.0 adapter on the board, but that costs money and has the exact same performance and chip as a HDD enclosure you can buy on Amazon for $8. So, with little demand from the community at large from eSATA and the fact that you can get equivalent performance on the cheap using an enclosure, why pay to build it in?
2. Space: There is no space on the PCB for an eSATA to USB 3.0 conversion chip even if RPT decided to add it. The Pi is actually a six-layer circuit, and spent over 6 months in design being ~5mm too wide because of the incredible difficulty in getting the current circuit to fit inside the Model B form factor. A brand new form factor would be necessary, but according to a recent interview, RPT has no intention to launch a hypothetical "Model C" anytime soon. There is no way to fit an eSATA to USB 3.0 chip onto the Model B form factor without adding more layers to the PCB's 6 - which is currently very expensive.
Further on this tangent, let's say that Broadcom/RPT spent the cash to build an eSATA connection into the SoC. That eSATA Connector has to go somewhere on the board, and considering that there wasn't room for a full size HDMI port or even room for two mini HDMI ports, there probably isn't room for an eSATA port either, without (again) a new form factor or increasing the amount of layers, which is already 6 layers thick.
Some good news: Shutting down your Pi correctly greatly reduces SD Card damage, Premium SD cards (+$5) last much longer than cheap ones, and the SD card bus is now TWICE as fast in the Pi 4. You will also get PXE and USB boot soon.
Why no RTC? RTC is SO NECESSARY!
1. Cost: The SoC has no RTC circuitry inside it. Adding such circuitry (like any SoC change) is a multimillion dollar job. Plus, once RTC is added, you need a coin cell battery, which plays right into:
2. Space: Read the answer to Space above for eSATA, except swap in a coin-cell battery. Absolutely no room on the PCB.
3. Health Risk: Coin cell batteries are frequently swallowed by children, easily lost, and because the target audience for the Pi is children who might have smaller children in the same house, this is potentially quite dangerous.
4. RTC kits: It's annoying, but you can get RTC kits for your Pi for $10-$15. Even if RTC could fit on the board, is it really worth spending that cash and raising the price to about $40-$50/Pi just for RTC? Or starting a whole new SKU and all of the problems with that? (See No eMMC / Cost).
Overall, it appears that those who want RTC have options. It's not built in, but this helps keep the cost down for everyone else.
Why so late with the 1GB of RAM? Looks like the community was right, we needed more than 1GB, but the RPT was just a we-know-better-than-you, we-can't-do-it type of organization all along and only now has finally admitted it.
The SoC in the Pi Zero-3B+ actually could not handle more than 1GB of RAM without a multimillion dollar redesign of critical components. This means that the RPT could not have offered more than 1GB of RAM even if it wanted to (which it did).
With the Pi 4, the GPU is upgraded to VideoCore VI. As part of this, some reused work from Broadcom, some reused bits and pieces from the Set-Top-Box division of Broadcom, some very complicated RAM tricks during boot, and upgrading from a LPDDR2 to LPDDR4X controller, more than 1GB of RAM is finally an option for the first time. Some parts of the GPU (e.g. video decoders) are still limited to 1GB of RAM because they weren't upgraded, but they will never need more than 1GB of RAM, and thus this is a non-issue.
Finally, chips like this major redesign take time. This chip was actually being conceived of and designed about 3 years ago. It took 3 years to get from then to now. At the time, the Pi 3B had just launched when this chip was getting designed. It takes time for all major changes.
Why microHDMI? Please go back! I have to buy a D!@#LE!
The RPT doesn't like microHDMI either. It's more expensive than miniHDMI and costs about the same as full-size HDMI. You need a dongle. They get it. But, here's the catch.
The SoC allows for up to two HDMI displays. One could possibly be terminated, but a big buyer of Pi's is digital signage, and two displays has been a long-standing request. You might say that the RPi is "education first," and that digital signage buyers aren't that important, but RPT needs to make money and sell a minimum amount of units to justify upgrades and satisfy minimum-order requirements. This is what a very large market for the Pi wants, and if it can increase sales, that allows more money to go to the Foundation and R&D. That's just how business works.
As for some objections to microHDMI...
Q. Why not DisplayPort?
A. DisplayPort isn't supported by the SoC. Multi-million dollar project from scratch, because AFAIK Broadcom has never developed this before as a mobile chip option. Plus the plug is larger than HDMI, and mini-DisplayPort is pretty niche.
Q. Why not HDMI over USB-C?
A. It isn't as simple as that. That requires (again) a non-trivial SoC upgrade. Plus, you would then need to separate the power side of the USB-C port from the data lines, which may require a previously-nonexistent adapter. Finally, the USB-C port works because most if it's data pins are disconnected. Connecting those pins would not fit in the already-crowded PCB without a significant redesign and possibly a new form factor.
Q. Why not stacked HDMI?jamesh wrote: ↑Thu Jul 04, 2019 10:59 amI posted elsewhere, but video over USB-C is a PITA due to the extra protections chips you need to include to prevent the design fault in the USB-C connector of having the high voltage next to the display lines causing problems with the SoC. The connector, if twisted, can short those lines, causing a spike to destroy the SoC video output circuitry. So you need an extra protection chip to prevent this from happening. An expense we are not willing the bare.
A. Too large, plus the bending moment created by inserting an HDMI plug into the top slot was so great, that there was risk of cracking the PCB. It was also uncomfortably high and took up too much board space.
Q. Why not miniHDMI, like the Zero?
A. Board space is so tight, that there wasn't enough room for the copper traces even in miniHDMI. microHDMI was literally the only port that fit - after months of investigating other ports to see if they would fit.
Q. But microHDMI is such a weak connector!
A. The RPT spent significant time and energy on ensuring that the microHDMI connector was extremely stable during production. It should have above-typical stability and the likelihood of ripping out of the Pi's mainboard or cracking something is much lower than stacked full-size HDMI.
Q. But I need a dongle, or a new cable!
A. Dongles will become more common in the future. In America, this is like whining about how a $5 adapter is needed for a $35 computer. The RPT wisely timed this with the switch to USB-C, because if a major disruption is necessary, better to do both at the same time.
Why not 4 USB 3.0 ports instead of 2?
USB 3.0 connectors cost more, and there wasn't room for the extra wires required for 3.0 on the PCB without causing interference. You don't think that the Ethernet and USB ports were switched and extend an extra millimeter for no reason, right?
Some claims are available online that this is a SoC limitation, that you can't have more than 2 USB 3.0 from an SoC perspective. This is not technically true, as the USB 3.0 is connected using a bridge chip which runs the USB over a single PCIe 2.0 lane. Space issues and cost of USB 3.0 jacks was the primary limitation, and with the limited bandwidth, it doesn't make sense to add to more if they can't be used at full speed. So, you could have four USB 3.0 jacks - but it doesn't make much sense.HawaiianPi wrote: ↑Wed Jul 03, 2019 11:44 pmIn addition to what was said, all 4 USB ports are connected to a single PCIe lane with 4 Gbps shared bandwidth. A normal USB 3.0 port is 5 Gbps, so the two USB 3.0 ports on the Pi4 are already below spec. Sharing bandwidth with four USB 3.0 ports would only reduce performance further.
Why USB-C Power? I want barrel jack!
USB-C had significantly more power available through spec than microUSB, and is becoming more common on mobile phones. This is necessary due to the Pi 4's higher power demands.
Okay, but why not a barrel jack? The reason for this is partially the RPT's preference, but also because there are much more kids out there with a fast USB-C phone charger than a barrel jack plug. The fast USB-C phone chargers aren't enough to run the board at full speed or with overclocking, by any means (2.1A vs 3A), but it's better than nothing.
Another reason is that USB-C is much shorter in height and takes up slightly less board space than a barrel jack. This means barrel jack may have a higher risk of board damage if bent downwards, which may weaken the PCB more than USB-C will (though the effect may be small). Only the engineers know for certain if this could be an issue.
Finally, the USB port on the Pi has the legacy USB 2.0 connector on the SoC that was used in the earlier Pi's connected to it. This means that if someone had a USB OTG adapter, they can potentially get USB 2.0 from that port, which could be useful in embedded uses. The barrel jack has no such ability.
DougieLawson wrote: ↑Wed Jul 03, 2019 10:20 pmThe missing piece about barrel jacks is the lack of a polarity standard. Nobody knows whether the pin or the sleeve should be +VE or -VE. Get that wrong and $35 to $55 worth of kit instantly goes bang as the magic smoke rapidly escapes. USB-C may be a pain (when we're used to micro USB-B) but it's a good choice.
HawaiianPi wrote: ↑Wed Jul 03, 2019 11:44 pmPolarity isn't the only problem. There are no voltage standards for barrel jacks, and they're not even guaranteed to be DC!
Imagine the chaos that would result from a Pi that used a barrel jack.
jbeale wrote: ↑Wed Jul 03, 2019 10:37 pmRe: DC barrel jack power connector, I have plenty of them! I have a bunch of 5V, 9V, 12V, 15V, 24V and 48V supplies, all with the same 5.5/2.1mm barrel type plug. I even modified a few of my Pi boards, soldering the 5V and GND GPIO pins to a power jack. Guess what can go wrong?
Also: I worked for a company that made a consumer device that charged its battery with a 5V barrel jack. Unbeknownst to us, a reseller in Japan had some extra-special deal and bundled our product with a totally unrelated rice cooker machine that happened to use the very same jack for something like +24V with substantial current. Were there some unhappy customers after that? I'll let you guess.
Why did you flip the USB and Ethernet? My case doesn't fit!
The PCB was extremely tight, and it was the only way to fit the Ethernet and USB ports on it without making the PCB larger - which would really make your case not fit. With this design, the Pi 4 somewhat fits old cases, whereas growing the board and keeping them in the same order would make the Pi 4 fit zero old cases. The RPT figured that flipping them and maintaining some compatibility was the better choice.
Why no built-in PoE?
Read some of the above problems, and they typically revolve around cost, lack of demand, and board space problems. This one has all three. Just buy the PoE HAT - it exists for a reason. Adding PoE, even if it was possible to fit it in the board (which it is not), would make the Pi start at $50 for something more than 90% of users will not use. It's not worth it.
Why is the UART not dedicated and still have Bluetooth problems?
Updated:
dickon wrote: ↑Wed Jul 03, 2019 10:17 pmOr, better, simply enable one of the other five UARTs, and use that...
(See pp10 of https://www.raspberrypi.org/documentati ... minary.pdf)
One of the really, really good things about this version: six UARTs or I2C buses on a variety of GPIO pins. Excellent stuff.
Why's the video decode in Chromium so bad? It can't even play 1080p smoothly!trejan wrote: ↑Wed Jul 03, 2019 10:21 pmOne of the new features of the RPi 4 SoC is that it now has 6 UARTs. The devicetree says the new UARTs are PL011 compatible and the pinmux should be able to get them on the expansion header. One of them does use GPIO 0 + 1 which is ID_SD and ID_SC so not ideal but the rest are fine.
The GPU Decode for Chromium is disabled due to a bug which could lead to a kernel panic. In a few weeks, this will be fixed and hardware decode will be re-enabled. In the meantime, any reviewer showing off terrible performance in Chromium: Yeah, what do you expect from 100% software decoding? That's not shocking.
I couldn't get 4K video to play without aggressive stuttering in Kodi/VLC/other. Help!
The Pi supports the following formats:
- MPEG-2 and VC-1 software decode (performance is good enough that the previous built-in HW decoders were removed in Pi 4)
- H.264 @ MAX 1080p (no 4K H.264 here)
- H.265 @ 4K30, 4K60.
The H.265 currently only works in LibreELEC. Kodi, VLC, and Chromium in Raspbian do not have the patches to play H.265 4K60 yet. They're coming soon!
The Pi 4 is really HOT!!! What gives? I need a cooling fan! It also throttles!
Depending on what you do (such as overclocking), you might need a cooling system. However, a patch is coming in a few days/weeks which has been independently confirmed for reducing temperatures by about 3-5C, because a power management technique was disabled with early firmware. It should also help improve the throttling situation. Just be patient - it may get much better soon.
The Pi 4 uses a lot of power! But I use batteries!
The faster you go, the more energy you use. If the Pi could use no energy at all, that would be incredible - but the laws of physics have no appeals court. However, thanks to the wonderful thing called backwards-compatibility, you could always set up your project on the fast Pi 4, eject the SD card, and plug into a more power-efficient (but slower) Pi Zero. Or you can get a bigger battery pack.
Why no Model C?
Like any business: What would it cost, how many people would buy it, and would it justify the time required to make and support it?
Let's say the Model C had built-in PoE, built-in eSATA, two full-size HDMI, a bigger PCB, more RAM, the whole caboodle. How much would it cost? How much profit margin would be necessary to justify the far fewer buyers? How could it stay competitive against the low-end x86 or RK3399?
The point is, the RPT doesn't see the business value in a Model C offering at this time. Never say never, but don't complain if it doesn't happen and please don't post your "Model C" or "Raspberry Pi 5" wishlists. RPT engineers aren't dumb - they know what you would want, and they know what you would want before you know it. If you need Model C features, you might want to consider a board other than the Raspberry Pi. The Raspberry Pi is just not for that market at this time.
Why no 64-bit Raspbian?
Raspbian is currently 32-bit ARMv6hf - and there are plenty of complaints about why Raspbian isn't 64-bit considering the Pi 2 and up have 64-bit processors. Here's why.
1. The Pi 1 and Pi Zeros use 32-bit ARMv6hf processors, while the Pi 2 uses an ARMv7, and the Pi3+ use ARMv8. Assuming you mean Raspbian in 64-bit ARMv7, that build would only work on the Pi 2 and up. This would break backwards-compatibility with earlier boards, and would remove your ability to develop your software on a fast Pi 4, take out the SD card, and place it in a power-efficient Pi Zero without major changes to your project.
2. 64-bit sounds impressive, but in the RPT's testing, there is actually very little (if any) measurable performance improvement. On the Pi 4 4GB, it makes a little more sense, but the performance improvement is still small.
3. 64-bit binaries are significantly larger than 32-bit binaries. This takes more time to download, takes up more SD card space, and takes up more RAM when running on the Pi - or on any computer, for that matter.
4. Besides increased hosting costs because of larger file sizes and worse performance on earlier Pi models, there is also the cost of development, maintenance, operating two incompatible versions of Raspbian at the same time, and all for a minor performance improvement which, depending on your application, may in fact cause a drop in performance.
Overall, a 64-bit version will probably eventually happen - but don't hold your breath, it's not truly necessary yet and there are more drawbacks than benefits for the time being.
Edit: A 64-bit Linux Kernel for the Pi 4 will probably arrive "eventually" according to @jdb, but this will have a 32-bit userland.
-----------
-----------jamesh wrote: ↑Thu Jul 04, 2019 10:59 amOn the whole, all the design decisions eventually come down to cost - what can we do inside our BOM budget. And the Pi4 is what we could do within the budget. If something is 'missing' it will be because of cost. It's as simple as that. Arguing that something only adds a tiny amount to the cost ignores the fact that tiny amounts add up to a lot of money when you sell as many devices as we do.
Of course, 'cost' means a number of things. The cost of components, the costs of adding a feature to an SoC, the cost of developing software. Some are ongoing, some are one off costs that need to be amortised.
Suffice to say, we spend a LOT of time making sure we give the best value for money, so arguing we 'got it wrong' just makes us snigger. We know what was possible, we know how much it cost, we know the effort that went into that BOM equation.
Any thoughts / comments / something I forgot? This is all of the standard-issue complaints I could think of for now.
Edit: I previously used RPT/RPF interchangeably by mistake. RPT is short for Raspberry Pi Trading, which does the R&D. RPF is Raspberry Pi Foundation, which makes educational materials. RPT is the true developer of the Pi board.
Edit 2: More info on Barrel Jacks and UART. Thanks!
Edit 3&4: More of the best commentary added inline. (+ Minor readability edit)
Edit 5&6: Added yet more commentary inline. Plus some balancing of opinion. Added new section on 64-bit Raspbian. (+64 bit kernel edit)
