I hate companies using the same name for different products. B+2 (or is it 3?)?
Edit: Didn't realize you meant the title.
In the blog, they mentioned the possibility of having a Pi3A too, so I look forward to that as well. The project I have has not much need for lots of USB ports and ethernet, so having to pay for and power a hub and an ethernet port only add to the power requirements with no added benefit. The Pi3A will be the prime target for me if they release it.
The only thing I wish they had is microphone input (we need the mic input for "OK Google") but I don't think it will happen, so that's one more thing on the wish list.
PS: Upon further inspection, PXE netbooting is already possible on the 3B under the name of "USB booting," it's just not the default in the hardware, and there might be bugs that are fixed in the new version.
And at this point, if you already use an SD card for the bootcode, might as well put the whole U-Boot onto the card (which I did)
This is something we don't do well. Situational awareness and expert consults. As a society, field, and individuals.
Opportunities for improvement are coming. Hybrid human-computer systems, so "I'm planning to do X, can I get a sanity check?" can be addressed with a mix of automation, and AI, and stats, and custom blends of variously-skilled/expensive human expertise.
But there are existing opportunities which are often not taken advantage of. Like maintaining personal review "committees" - people of various expertise to whom you can mention what you are up to, and hope to at least get back a "sounds good"/"have you thought of instead doing X". And like watching for opportunities to mention one's work on fora like HN, to create an opportunity for feedback. :) Engineered serendipity.
Very unfortunate that their in-house developed and promoted OS ("Raspbian") only supports armv7, thus leaving the vast majority that doesn't know about the existence of (or how to use) archlinux ARM an the likes with a 32 bit os. Am I the only one that doesn't get the sense out of this here? Debian supports Aarch64 out of the box I think.
The other day, there was a person who had a "reddit gold" bounty for the first person who can help them get the Pi 0 online. The person basically couldn't get the Pi Zero on the wireless network. They had no USB-OTG adapter or mini HDMI adapter they could use to debug the Pi Zero. I was thinking something along the line of making the Pi USB port a USB-serial gadget, but it was still cumbersome. The "accepted solution" was to pull out the SD card for the Zero, put it into a Pi3B they had, get the 3B online, and put it back to the Zero. I think that was such a brilliant idea.
Making it easy for users to achieve such tasks is often overlooked by us who "know too much" to not care about the efficiency of the new hardware. I don't think it was an accident that the Pi is so ubiquitous in education: They made a lot of right decisions to make their product easy to use.
I have yet to find it - you can get them cheap, but no where near what the RPi Foundation advertised them at when they first were announced/launched.
Several online places have them for $5, but shipping 'kills the deal' as they say.
They also sell the normal RPi3 for $29.99 instead of $35.
You can very easily† pop in an ArchLinux ARM AArch64 in there and notice that you only get a very basic framebuffer, sound is just not working at all, and the bootloader is quite incomplete. So ARMv7 it is for me, even with ArchLinux ARM and in spite of my wish for better FOSS support from Broadcom or in Linux mainline.
† I find alarm much much better as a distro than raspbian as it's incredibly straightforward to install, maintain, and use, while vanilla debian is downright painful.
Most x86 boxen tend to run tons of proprietary firmware but at least that isn't pinning me down on ancient hacked-up kernel trees.
You get 3D accelerated Wayland or Xorg with the open source VC4 driver!
Doesn't the firmware run on VideoCore anyways, so why would its bitness matter?
Closed ARM-side libraries are of course a different beast.
People who actually have a use for 64bit on their pis will generally know what to do, and I'm guessing most of of them won't have a whole lot of use for the streamlined UX that is Raspbian's raison d'etre, anyway.
Don't most ARMv7 CPUs (like A7, A15, etc.) have 1 TB address space? On LPAE ARM, 64-bit arch will only get you larger virtual address space, but you get same 40-bit address space in both cases.
> reduction in memory consumption that comes with pointers that are half as big
Nothing prevents you from running 32-bit binaries on 64-bit OS, as long as you have 4kB page size.
I can see having a bit of headroom for virtual memory, but I wouldn't want to actually use it. The non-volatile storage on this computer is an SD card, so paging will be particularly expensive. Are you really going to have more than 3GB of swap? That's a pretty big appetite for thrashing.
Regarding running 32-bit binaries on 64-bit OS, sure, and the code that lives in those binaries will run faster. But you'll still be needlessly taking a hit on the 64-bit kernel and userland.
Looks like I should have communicated it more clearly.
AArch64 does have some perks, but mostly for out-of-order cores, which RPI3's Cortex A53 is not.
That said, even A53 can benefit from 31 registers in 64-bit mode. Large virtual address space is nice not only for memory mapping files, but to do lazy initialization while keeping high performance direct pointer access characteristics. That way you can have the MMU doing the check and indirection for you instead of slow explicit conditional check in code.
You can mitigate pointer size by ensuring memory accesses are PC-relative. Perhaps there could be support for something similar to x32 ABI  as well.
AArch64 codegen does need to generate more conditional jumps or CSELs (like cmove) though. Also function entry & exit code is larger due to lack of LDM & STM (load/store multiple). But on the other hand, stack spills are rarer, thanks to 31 general purpose registers instead of 14 on 32-bit ARM.
Where AArch64 truly shines is when you have a real out-of-order CPU core, for example Cortex A72. There are significantly more opportunities for instruction level parallelism due to dropping instruction predicates and other changes.
The foundation is overlooking the most unique feature of the Broadcom chipset, the 3D video support. They already have implemented the software/driver side, so only thing required is just exposing the pins from the SOC and adding second camera connector – very low hanging fruit. (The Zero board may not have enough space for routing but the bigger boards definitely have.)
I can see that being made into very compact 3D Scanners very quickly after launch if that was added as a feature.
Also is it possible to browse the web and e.g. watch videos on youtube with adequate performance on an RPi? (different topic)
I've streamed 3D video over wifibroadcast¹ to OSVR headset, no fundamental issues. The exact lag depends on resolution, fps, etc settings. It would be superb to cut the delay to sub-50 ms range, but that's probably not going to happen as it would require major rewrite of the H264 stack, as currently there are always two full frames in the pipeline, e.g. in 30 fps it makes 1000/30*2 -> ~70 ms delay². (Note that I'm not the author of the befinitiv website.)
The foundation has released open-source driver stack³ (raspivid etc), but AFAIK they have rather limited resources for software development (single ex-broadcom developer?) and limited access to proprietary features (documentation?) of the Broadcom chipset. Many things work but I think the capabilities of the SOC aren't yet fully utilized.
> Also is it possible to browse the web and e.g. watch videos on youtube with adequate performance on an RPi? (different topic)
No personal experience, but RPi 3 should be okayish for lightweight desktop use (YMMV) with 1 GB of RAM being main limitation for multitasking.
It's really not that hard or expensive to do it yourself, and it's a fun little side project. Try it out.
(That way you can prepare image that boots both on RPi and Tinkerboard)
Example hybrid image for Tinkerboard and RPi is here (based on Ubuntu): https://files.husarion.com/husarion-core2-ros.img.xz (unfortunately the build scripts are not public yet)
4 gigabytes of LPDDR3. USB 3. GbE. eMMC. Onboard SPI flash. Unfortunately Mali GPU, but lima is actively developed now…
The biggest downside for me is Rock64 doesn't have an OS with the pedigree of Raspbian. I'm running the 'ayufan' minimal ubuntu xenial, and it seems solid. but when I've played around with a monitor in the full xenial build I've seen some crashes and lockups.
and really any Linux distro can be installed like that
+ "soon", FreeBSD (possible to boot already, but very few drivers have been already written https://lists.freebsd.org/pipermail/freebsd-arm/2018-Februar...)
Not to say Broadcom couldn't spin a newer revision of the SoC with a different internal architecture, but for now it seems that >1 GB of RAM would require substantially more effort than just swapping the DRAM module on the board.
Later versions (I think starting with RPi 2) have a separate DRAM chip on the bottom side of the PCB.
Now it will be faster than 10/100 ethernet connections but don't expect to send a 100 megabytes/second through it.
> While the USB 2.0 connection to the application processor limits the available bandwidth, we still see roughly a threefold increase in throughput compared to Raspberry Pi 3B.
And then show that they're typically seeing 314Mbps for TX/RX in iperf.
"GbE is 1250Mbps"
1.25Gbps is the "gross" bit rate for 1000BASE-T Ethernet. This is because it uses 8b/10b encoding on the wire (meaning there is a 25% overhead):
1000Mbps is essentially the "net" bit rate available to the Ethernet protocol.
The video is 1 minute long. The article is ~84 lines, ~8 KB of text. Is that really long?
One of the basic skills that an instruction gives you is the ability of quickly reading and categorize informations as you go.
When you went through studying tons of books, skimming short texts becomes a breeze.
Strangely it was quite easy when I had a stab at Swedish a few years ago; a number of their TV channels have a free streaming service that you can access from anywhere.
The good thing about Audible or books on tape, is that you can read along with the exact same text, whereas movies with subtitles are often translated with completely different sentences in an attempt to convey similar meanings from the original language to the translated.
I've even managed to find a few shows where they didn't even bother to allow disabling the subtitles!
Same clusterfuck as with other copyright things. Different companies have the rights to the subtitles and it depends on what terms Netflix got. One of the reasons  I mentioned why piracy is still superior even for someone paying and wanting to pay.
It’s not documented and totally not intuitive, I only discovered that by accident, but it works very well.
Reading and writing were much easier than listening and speaking to me.
This is nice though I personally wish they used the same Silvertel PoE module as Arduino which you just solder onto the board. Plus their PoE hat has a spinning fan.
Plus their PoE hat has a spinning fan.
Definitely, the Pi Zero W is now my go-to controller for almost anything that needs one. The fact that Microcenter frequently sells them for $5 seals it.
I pair them with a $15 aMLC (MLC in SLC mode) industrial MicroSD card, and they've been rock solid, no FS corruption on power loss, no Wi-Fi drop outs.
The ability to add the Pi Camera board and have a tiny full HD networked camera with trustworthy "firmware" is a killer feature though, pre-made IP cameras at any price tend to have outdated insecure or even malicious firmware that may or may not be replaceable.
Model B... Model A... Model B+...
When can we expect to see the Raspberry Pi Master and the Raspberry Pi Master Compact?
Raspberry Pi Air
Retina Raspberry Pi
Let's see how much the official PoE HAT is, but it better be cheap or I know what I'll be buying (more of)
I have 2 in my home (not the exact model I listed because I'm on the other side of the Atlantic, bought them off Amazon Germany), hooked to a Netgear GS110TP (8 PoE copper ports, 2 SFP ).
Actually there's so much stuff drawing power (2 Pi, 2 Ubiquity APs) that I'm starting to worry about the load on the switch.
Made a project in optics with the pi zero w, camera v2, a touchscreen over GPIO, 4 bright LEDs and a 5V regulator.
As a power source it uses a 9€ 1200mha LithiumIon Battery in 9V battery form. Lives on for 3 hours under full load.
Also using normal 9V batteries I killed them in 5mins - something something internal resistance of non LithiumIon batteries not coping with high current draw.
FWIW if you need gigabit you can get it on the (now old) cubietruck 3, which is an excellent SBC and even has a SATA controller.
EDIT: I should say (that's independent whether you use Raspberry or BananaPi) that both run for months without intervention. The only thing I found to be important is a good power source. I had frequently file system errors due to dying (somewhat cheap) chargers used as power source. I finally got a switched 50W multi charger (10 outlets á 2A) which I connected all Raspis and Bananas to. Since then, everything works pretty smooth.
Also how does it act once its internal receive buffer is full? Is it possible to get the sender to slow down, or does it have to start dropping frames? Will important things such as ARP broadcasts and DHCP requests just risk getting lost?
> While the USB 2.0 connection to the application processor limits the available bandwidth, we still see roughly a threefold increase in throughput compared to Raspberry Pi 3B.
Followed by a table showing 315Mb/s bandwidth, three times that of the 3B but a third that of full-speed Gigabit. And this isn't tucked away in a footnote, it's up front in the middle of the article.
> 1.4GHz 64-bit quad-core processor, dual-band wireless LAN, Bluetooth 4.2/BLE, faster Ethernet, and Power-over-Ethernet support (with separate PoE HAT)
I'm a bit cross because of the casual assumption of bad faith, when it seems to me they've gone to some effort to do the opposite: make the limitations clear instead of relying on a buzzword.
Basically any protocol out there has some way of dealing with dropped packets (including UDP's "don't care")
DHCP requests are usually repeated several times for this reason, the first one can get lost (this can and will happen even on a clean and underloaded gigabit homenetwork)
Traffic shaping on higher layers usually lets some packages deemed important through while dropping bulk traffic, tcp which is usually used for bulk transfers backs down when packages gets dropped, but that only gets you so far if you keep getting hammered with new connections or the sender acts maliciously.
Not if, it does. The repeats are usually good enough to get into the receiving buffer. If there is constant noise on the interface that it even interferes with basic protocol operation you're probably running something that doesn't know how to throttle the connection properly. Those things are usually best retrofitted with some form of ratelimiting in the kernel.
But yes, in this case you wouldn't be able to do DHCP or ARP. This is also true for any further hops on the network. If the receive buffer is full there isn't much you can do about it other than try again later. And "try again later" is purely a protocol decision.
On an internal network the fix is usually to have a Switch that can ratelimit a peer. Otherwise, there is no protection and you can easily replicate the effect by taking an old switch and patching up a loop. The resulting packet storm can easily shut down larger networks.
On the larger internet, the telco's and ISPs are largely responsible for making sure their receive buffer doesn't get full.
Edit: The Wikipedia article says: "By 1999, several vendors supported receiving pause frames, but fewer implemented sending them. Pause frames have several disadvantages.".
Any idea what the situation is like today?
Of course you're usually not going to see them even when using Wireshark etc., because they're handled at the MAC hardware level.
I'm not aware how to reliably determine whether link partner has L2 flow control / pause frames enabled. But at least you can check whether it's locally enabled:
ethtool -a eth0
ifconfig en0 | grep media
Note that above only applies to wired ethernet, not wlan.
Also, as possibly the only person left who really doesn't care at all about wireless... I'm glad there's a refresh, sure, but... I'm meh. I've been pxe booting my pi3s for a while now.
Now, if it had official "clean" debian support (not "raspian") that would be something!
If anyone hear is looking for a true upgrade on the Pi, try the ODROID C2, it's years ahead of the Pi in terms of performance.
The price of an Odroid XU4 is significantly proportionally higher and I have no guarantee that certain features or projects are feasible on it. First result from Dec 2017 when searching for "XU4 Kodi" is someone having a problem installing and then saying "I would prefer a version with long term support and wide use base." Well my answer to that is RPi.
I'm merely implying that RPi has a higher chance of certain things working simply because its more popular. I'm not disputing that there are higher performance platforms for "similar" money but it's reliability and a little more certainty that some people are after.
I would love to try one of the ODROID devices, I simply don't have the time. And I love seeing suggestions for these other devices so please don't stop posting them :)
However, the ODROID C2 is priced similarly to the Pi and has more support than the XU4. LibreELEC has out of the box support for the C2.
Then you get people who do projects that would fit on 8 bit processor, like reading sensor and then switching relay depending on sensor value. That is gross overkill.
If you have more ambitious projects like streaming video, which I have seen somewhere in thread, or mining cryptos, maybe RPi is not best choice.
The experience with ODROID C2 on the other hand is superior.
I'd pick one from here: https://archlinuxarm.org/platforms/armv8
> There is virtually no reason to get the C2 now
I disagree with this though. The price difference between the two isn't insignificant.
If someone intends to deploy hundreds of devices for an IoT application the price difference between the 2 would be one of the reasons to choose the C2; the other reasons would be size and heating problems.
When are they going to upgrade the memory? All of that is nice, but what I've really wanted is one with at least 3-4GB.
Do you have any advice or feedback on Amlogic S905X-based boxes that can have the OS flashed to something more generic (Debian-based, ideally)? Thanks!
I agree about the ecosystem. As long as you just want to use it as a mediacenter all you care about is that LibreElec with Kodi works well.
WHAT IS THE SAME:
- Same mechanical footprint as both the Raspberry Pi 2 Model B and the Raspberry Pi 3 Model B.
- Same GPIO pinout, so no need to change your hats/shields/daughter boards
- Same power supply recommended (5V/2.5A DC via micro USB connector)
- Broadcom BCM2837B0, Cortex-A53 64-bit SoC (System on a Chip), but this time clocked to 1.4GHz, which yields roughly a 10% performance increase over the Raspberry Pi 3 Model B. The chip now has a metallic heatsink and bears the markings BCM2837B0 1FSBG, TA1738 P20 W39-01 N2 W.
WHAT IS NEW:
The product briefing document from the foundation states that the onboard wireless module now supports dual-band 2.4GHz/5GHz IEEE 802.11ac and both Bluetooth 4.2 and BLE (Bluetooth Low Energy).
The wireless module in the RPi3B+ is not mentioned in the product briefing document and is hidden under shielding. Prying open the shielding revealed a Cyprus Wireless CYW43455 (datasheet).
- The CYW43455 supports the following WiFI standards: 802.11ac/n/a/b/g/d/h/i
- Security: (WEP/ WPA Personal / WPA2 Personal / WMM /WMM-PS (U-APSD) /WMM-SA / AES (hardware accelerator) /TKIP (hardware accelerator) / CKIP (software support)
- Proprietary protocols (CCXv2, CCXv3, CCXv4, CCXv5, WFAEC
- IEEE 802.15.2 Coexistence Compliance (on-silicon solution compliant with IEEE 3-wire requirements)
- The CYW43455 supports the following future IEEE drafts/standards: 802.11r (fast roaming between APs), 802.11w (secure management frames), 802.11 Extensions:, 802.11e QoS Enhancements (as per the WMM specification is already supported), 802.11h 5 GHz Extensions, 802.11i MAC Enhancements, 802.11k Radio Resource Measurement
The CYW43455 data sheet states that the Bluetooth core supports:
- Bluetooth 2.1 + EDR
- Bluetooth 3.0
- Bluetooth 4.2 (Bluetooth Low Energy)
The Wireless LAN module now has "modular compliance certification", which allows the board to be designed into end products with significantly reduced wireless LAN compliance testing, improving both cost and time to market.
NEW GIGABIT ETHERNET:
The new RPi3B+ has support for Gigabit Ethernet using Microchip's LAN7515 (which is a USB 2.0 to 10/100/1000 Ethernet Bridge with 4-port USB 2.0 Hub). The LAN7515 supports a max number of 6 downstream USB ports and 1 Ethernet Port limited to a maximum throughput of 300 Mbps.
The LAN7515's ethernet controller supports numerous power management wakeup features, including Magic Packet™, Wake-on LAN (WOL) and Link Status Change.
The RPi3B+ is Power over Ethernet (PoE)–enabled, but requires the purchasing of a separate PoE HAT.
If you're thinking of incorporating the Raspberry Pi 3 Model B+ into another product, the Raspberry Pi foundation has committed to keeping the RPi3B+ in production until at least January 2023.
Due to the BCM2837 now running at 1.4GHz, the RPi3B+, runs relatively warm. The foundation provides the following warning: "This product should be operated in a well-ventilated environment and, if used inside a case, the case should not be covered". Given the optional "open lid configuration" of the official Raspberry Pi case I asked for clarification, and their Director of Product Management came back with: "It only means if you have it in a case the case itself should not then be covered".
Does this make the B+ model more dangerous in case of overheating?
I have a couple of Pis running inside official Pi case they hold between 35 - 53 degrees. ( 35 meaning unheated room ). I would be sad if I upgrade the devices and then loose my sleep in case of overheating.
3A has similar issue, when it overheats it automatically drops CPU clock to afair 60% of normal until temperature drops down.