Raspberry Pi 3 B+ Board Released - 3/14

[sfx2000]

Not sure where to post this - @thiggins - please feel free to move it to an appropriate forum.

The RPF dropped the Pi3 B+ earlier this week - for the community at SNB, here's the relevant data points.

1) Dual Band WiFi - now has 5GHz 802.11ac support

2) Bluetooth 4.2 - nice update there

3) 1Gbe Ethernet - they replaced the previous Microchip USB Hub/Fast Ethernet chipset with an updated version - still goes thru USB2, and shares I/O with the USB2.0 ports, performance there is better - around 300Mb/Sec as compared to Pi3 at 95Mb/Sec - so nice update there

4) POE support - the new ethernet port supports POE, and RPF is planning to intro a PiHAT to support things there

5) Network/PXE Boot - Pi3 has network boot already, but was always a bit flaky - they've debugged their firmware, and now it is well sorted

6) Better power management - they've moved from discretes over to a Maxlinear PMIC - this helps with power and thermals

7) The SoC - BCM2837 - minor speed bump, new package, and with the PMIC, better performance under load.

Still has the same linux support (via Raspbian, etc, WinIOT support is pending)

Nice overview here -- https://hackaday.com/2018/03/14/ras...u-and-better-networking-in-the-new-model-3-b/

I've got a board on order, and will do a quick writeup once I get a chance to kick the tires a bit.

 

[thiggins]

Too bad they cheaped out on the Ethernet interface.
Would be interesting to see if the onboard Wi-Fi supports monitor mode. It's BRCM based, right?

 

[sfx2000]

Too bad they cheaped out on the Ethernet interface.

The 2837's USB is still USB2, same with upstream on the Microchip LAN7515 - the SoC is basically a repackage of the Pi3 - nice to see the bump, but it's going to be throughput limited...

Would be interesting to see if the onboard Wi-Fi supports monitor mode. It's BRCM based, right?

On my list of things to check out - but based on previous experience with that line of chips - brcmfmac, so it really depends on what the driver wants to share.

The driver hasn't been very friendly with monitor or packet injection modes in the past. For normal ops, the Broadcom/Cypress chips have been fine for client usage. Not clear how hostapd will work at present, but again, history on that chip family and drivers...

(broadcom has two architectures - smac and fmac - the Soft MAC's we see with Router's and AP's, along with higher end client chips like the BCM4360 - the Full MAC chips, most of the functionality is in the chip itself, and these are mostly SmartPhones and Tablets, along with IOT targeted low power chips. It's not that they're bad, just focused on certain use cases)

 

[sfx2000]

Thoughts here is that they've taken the platform about as far as they can go - they're starting to hit bottlenecks with the VC4 on many levels...

While the Pi3/Pi3+ is running on a relatively current Arm core (Cortex-A53), it's the VC4 that drives I/O - and limits things - the VC4 hosts the arm's, and it also hosts all I/O. The VC4 has a max addressable memory space of 1GB, which they hit with RPI2, and it's 32-bit, so they tend to treat the A53's as really fast A7's.

There's a certain elegance to how they've evolved with HW - the Pi Zero W and Pi 3+ are simple, and the board designs here are very cost optimized... and it goes without saying that the real reason behind Pi's success is the software support behind it, along with the collective user community.

It's the SW and Community support that make RPi relevant compared to boards like NeoPI and the other AllWinner knock-off boards - there are reasons why I specifically do not support the AllWinner boards, mostly because they're smart on HW, but weak on SW support - if I'm going to do HW, it's like Marvell or Freescale/NXP...

That being said - my preference for RPF's next steps - take the Pi Zero and move it over to a single or dual core A53 - as it stands now, the Pi Zero is really a legacy device, and it's holding back SW development as it is ARMv6l - the Pi Zero is much like Apple's iPad2 from a couple of years back -- Allen Pike had a great article there...

https://www.allenpike.com/2014/the-ipad-zombie/

Moving the Pi Zero over - that's a lot of work actually, and it would really be on Broadcom/Cypress to make things happen there - but a Pi Zero v2 with dualband WiFi and Cortex-A53 would be a very powerful small board..

 

[FatherLandDescendant]

POE support - the new ethernet port supports POE

So I could power one through the Ethernet cable? I have a POE switch and that would be dam convenient for me as I'm running short on places to plug stuff in where all my tech stuff is at

I was just sitting here thinking about the pi3 I have behind the TV, I have pi-hole on it, but that whole issue with pi-hole and ipv6 made me shut it down and try pfBlockerNG instead which had the processor in my SG-2220 running at 75% constantly, it really slowed things down so I killed it too. Just never got back around to fiddling with the pi-hole but I'd like to get one back online.

 

[sfx2000]

So I could power one through the Ethernet cable? I have a POE switch and that would be dam convenient for me as I'm running short on places to plug stuff in where all my tech stuff is at

From what I've read, POE on the Pi 3+ still requires a HAT...

There are injectors already available for the Pi boards - not as nicely integrated as RPF's version will be, but they are available..

 

[sfx2000]

Would be interesting to see if the onboard Wi-Fi supports monitor mode. It's BRCM based, right?

Confirmed that the stock brcmfmac driver in the current raspbian does not support monitor mode...

In any event - outside of kismet and a few other tools - monitor mode is not useful for many... Not making excuses for RPF or other vendors - it's really hard to do monitor mode over the sdio interfaces - that the key reason why we have fullMAC chipsets in the first place - as full MAC puts a lot of the WLAN management on the chip, and not the OS. Not too much different than what we see with Android there...

that being said - Pi3+ is a nice point release - more in a couple of days... it's better at thermals, but it's more specific for power quality on the wall wart...

 

[sfx2000]

And for those who are curious about such things...

$ openssl speed aes-128-cbc aes-256-cbc bf-cbc

OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr) 
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/engines-1.1\"" 
The 'numbers' are in 1000s of bytes per second processed.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
blowfish cbc     32121.73k    36977.30k    38422.78k    38839.30k    38958.42k    38933.85k
aes-128 cbc      46767.17k    53605.23k    55692.97k    56181.42k    56339.11k    56393.73k
aes-256 cbc      37425.95k    40959.57k    42168.49k    42461.18k    42576.55k    42587.48k

 

[sfx2000]

WiFi support... nice step up in any case.

New chip support wide channels (according to the driver) for 2.4GHz, and it does support DFS for client in 5GHz mode for the US regulatory domain.

Also nice to see that Cypress is taking ownership of the chips they bought from Avago (e.g. Broadcom)

[    4.271710] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
[    4.590251] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[    4.590917] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2018-03-09 18:56:28

Getting to the chip capabilities...

$ iw list
Wiphy phy0
    max # scan SSIDs: 10
    max scan IEs length: 2048 bytes
    max # sched scan SSIDs: 16
    max # match sets: 16
    max # scan plans: 1
    max scan plan interval: 508
    max scan plan iterations: 0
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports T-DLS.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
        * CMAC (00-0f-ac:6)
    Available Antennas: TX 0 RX 0
    Supported interface modes:
        * IBSS
        * managed
        * AP
        * P2P-client
        * P2P-GO
        * P2P-device
    Band 1:
        Capabilities: 0x1062
            HT20/HT40
            Static SM Power Save
            RX HT20 SGI
            RX HT40 SGI
            No RX STBC
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT TX/RX MCS rate indexes supported: 0-7
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps (short preamble supported)
            * 5.5 Mbps (short preamble supported)
            * 11.0 Mbps (short preamble supported)
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (20.0 dBm)
            * 2417 MHz [2] (20.0 dBm)
            * 2422 MHz [3] (20.0 dBm)
            * 2427 MHz [4] (20.0 dBm)
            * 2432 MHz [5] (20.0 dBm)
            * 2437 MHz [6] (20.0 dBm)
            * 2442 MHz [7] (20.0 dBm)
            * 2447 MHz [8] (20.0 dBm)
            * 2452 MHz [9] (20.0 dBm)
            * 2457 MHz [10] (20.0 dBm)
            * 2462 MHz [11] (20.0 dBm)
            * 2467 MHz [12] (disabled)
            * 2472 MHz [13] (disabled)
            * 2484 MHz [14] (disabled)
    Band 2:
        Capabilities: 0x1062
            HT20/HT40
            Static SM Power Save
            RX HT20 SGI
            RX HT40 SGI
            No RX STBC
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT TX/RX MCS rate indexes supported: 0-7
        VHT Capabilities (0x00001020):
            Max MPDU length: 3895
            Supported Channel Width: neither 160 nor 80+80
            short GI (80 MHz)
            SU Beamformee
        VHT RX MCS set:
            1 streams: MCS 0-9
            2 streams: not supported
            3 streams: not supported
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        VHT RX highest supported: 0 Mbps
        VHT TX MCS set:
            1 streams: MCS 0-9
            2 streams: not supported
            3 streams: not supported
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        VHT TX highest supported: 0 Mbps
        Bitrates (non-HT):
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 5170 MHz [34] (disabled)
            * 5180 MHz [36] (20.0 dBm)
            * 5190 MHz [38] (disabled)
            * 5200 MHz [40] (20.0 dBm)
            * 5210 MHz [42] (disabled)
            * 5220 MHz [44] (20.0 dBm)
            * 5230 MHz [46] (disabled)
            * 5240 MHz [48] (20.0 dBm)
            * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
            * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
            * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
            * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
            * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
            * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
            * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
            * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
            * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
            * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
            * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
            * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
            * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
            * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
            * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
            * 5720 MHz [144] (20.0 dBm) (no IR, radar detection)
            * 5745 MHz [149] (20.0 dBm)
            * 5765 MHz [153] (20.0 dBm)
            * 5785 MHz [157] (20.0 dBm)
            * 5805 MHz [161] (20.0 dBm)
            * 5825 MHz [165] (20.0 dBm)
    Supported commands:
        * new_interface
        * set_interface
        * new_key
        * start_ap
        * join_ibss
        * set_pmksa
        * del_pmksa
        * flush_pmksa
        * remain_on_channel
        * frame
        * set_wiphy_netns
        * set_channel
        * tdls_oper
        * start_sched_scan
        * start_p2p_device
        * connect
        * disconnect
        * crit_protocol_start
        * crit_protocol_stop
        * Unknown command (122)
    Supported TX frame types:
        * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
        * managed: 0x40 0xd0
        * P2P-client: 0x40 0xd0
        * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
        * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
    valid interface combinations:
        * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
          total <= 3, #channels <= 2
        * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
          total <= 4, #channels <= 1
    Device supports scan flush.

 

[thiggins]

Confirmed that the stock brcmfmac driver in the current raspbian does not support monitor mode...

Thanks for checking.

 

[sfx2000]

WiFi support... nice step up in any case.

New chip support wide channels (according to the driver) for 2.4GHz, and it does support DFS for client in 5GHz mode for the US regulatory domain.

WiFi performance in 5GHz.... not terribly bad for an SDIO based single stream 11ac NIC... it's bus-limited as the Broadcom chip in the Pi3 maxes out at UHS-I speeds on that bus.

sfx@raspy3:~ $ iperf3 -c 192.168.1.20 -Z
Connecting to host 192.168.1.20, port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   129 MBytes   108 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   129 MBytes   108 Mbits/sec                  receiver

sfx@raspy3:~ $ iperf3 -c 192.168.1.20 -Z -R
Connecting to host 192.168.1.20, port 5201
Reverse mode, remote host 192.168.1.20 is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   124 MBytes   104 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   123 MBytes   103 Mbits/sec                  receiver

For the ethernet - see below - seems to be some unresolved flow control issues over the USB-LAN interface at the moment - not seeing this with the Rpi-3 (not plus) - in any event, like above, the Pi3 B+ is bus limited across the board, USB and SDIO, and I would suggest even on RAM

sfx@raspy3:~ $ iperf3 -c 192.168.1.20 -Z
Connecting to host 192.168.1.20, port 5201
[  4] local 192.168.1.150 port 49962 connected to 192.168.1.20 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   383 MBytes   321 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   382 MBytes   320 Mbits/sec                  receiver

sfx@raspy3:~ $ iperf3 -c 192.168.1.20 -Z -R
Connecting to host 192.168.1.20, port 5201
Reverse mode, remote host 192.168.1.20 is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   271 MBytes   228 Mbits/sec  4412             sender
[  4]   0.00-10.00  sec   271 MBytes   228 Mbits/sec                  receiver

 

[sfx2000]

Too bad they cheaped out on the Ethernet interface.

yeah, but this is also a limitation of the SoC - the USB interface is USB2, and the peripheral buses are hosted by the VC4, not the ARM's - see my comment about the Pi3's buses essentially being max'ed out - and that's all VC4...

Keep in mind that the BCM2835/2836/2837 chips - they're all VC4 based, and the VC4 is primary, the ARM's are actually riding on the side of the GPU - it's inverse of most small ARM SoC's

Would be interesting to see if the onboard Wi-Fi supports monitor mode. It's BRCM based, right?

Factory firmware as part of Raspbian, no monitor mode, as mentioned before -- that being said, there are some hacked drivers that do support monitor mode for the Pi's...

https://github.com/seemoo-lab/nexmon

It's a bit of effort to get things working there... one needs to roll up some sleeves - but the same drivers are also used for Android, that can be handy

 

[sfx2000]

Factory firmware as part of Raspbian, no monitor mode, as mentioned before -- that being said, there are some hacked drivers that do support monitor mode for the Pi's...

https://github.com/seemoo-lab/nexmon

It's a bit of effort to get things working there... one needs to roll up some sleeves - but the same drivers are also used for Android, that can be handy

@thiggins

Looks like the nextmon driver patch does support monitor mode - they have two patches - one for pi3/pi0w, and the other for pi3+ (different wifi chips) - there's a lot of caveats, and like I mentioned earlier, one needs to be comfortable with things under the hood - not for novices...

For some - monitor mode is needed for kismet, which is related to an article that is discussed here

https://www.snbforums.com/threads/build-a-wi-fi-performance-analyzer-for-75.44938/

Main Site - https://www.smallnetbuilder.com/wir...ld-a-wi-fi-performance-analyzer-for-75-part-1

Note that any pi2/pi3 can support a project like that with a realtek/ralink wifi NIC without the nextmon patches for the broadcom fullmac drivers on pi3/+/zeroW - the ralink drivers do provide more consistent data within kismet.

 

[sfx2000]

Too bad they cheaped out on the Ethernet interface.

It's been working pretty much the same as my TrendNet USB GiGe adapter I have on my other Pi3 - it's a gigabit PHY, but throughput is going to be limited - still better than 100BaseT on the Pi/Pi2/Pi3.

The TrendNet on Amazon is around $14USD these days...

So I wouldn't consider that cheaping out - Pi3+ is the same price as Pi3 - so considering the GiGe PHY, that's a plus.

The big thing with Pi3+ is the POE capabilities - the 'official' PoE hat should be available late August according to Farnell - and there it's a plug n play thing - with Pi's - there have been other PoE hats, but nothing as integrated as the 'official' PoE hat from the RPi Foundation.

 

[sfx2000]

There's a certain elegance to how they've evolved with HW - the Pi Zero W and Pi 3+ are simple, and the board designs here are very cost optimized... and it goes without saying that the real reason behind Pi's success is the software support behind it, along with the collective user community.

OS wise - Raspian Stretch is where it's at for the moment - they've been keeping things very much up to date with kernel and userland, and it's the best distro for folks new to the raspberry pi environment.

There are performance concerns about Raspbian and Pi2/Pi3 - Raspbian is armhf, and optimized for armhf on the original Pi - fair enough - note that there's the ARM-v7A kernel and libs to support Pi2 and later

So at the moment - the only Pi's I can recommend for folks that are interested....

• Pi3+ - that's the 'big' Pi with Cortex A53 - better cooling, better WiFi, better ethernet (GiGe/POE for some)
• Pi Zero W - it's really the only little Pi I would recommend - e.g. all the other legacy ARM6 - with WiFi/BT and USB-OTG, there's little reason to consider any of the other ARM6 Pi's other than the Zero W.
• Pi CM3 for embedded productization - CM1 is old-school, CM3/CM3Lite has the Pi3 SoC - I don't recommend the CM3L, go with the CM3 with the eMMC

Pi3+

Pi Zero W

Pi CM3

 

[sfx2000]

Here's some other numbers - byte-unixbench...

 

[kvic]

Many 3B+ resellers pack two heatsinks which are good. The first chip to stamp a heatsink is an easy guess. Most people if not all (from blogs and youtube) showed picking the wrong chip for a second heatsink...

Like most smartphones, 3B+ adds a power management chip. I see no people put the second heatsink there. Why? An interesting story about this new chip btw.

 

[sfx2000]

Many 3B+ resellers pack two heatsinks which are good. The first chip to stamp a heatsink is an easy guess. Most people if not all (from blogs and youtube) showed picking the wrong chip for a second heatsink...

Like most smartphones, 3B+ adds a power management chip. I see no people put the second heatsink there. Why? An interesting story about this new chip btw.

The pi3+ is pretty efficient at getting rid of heat - it's the packaging of the chip, and they throw heat back into the ground plane of the board... pretty smart, all things considered, and one of the primary reasons why the pi3+ outruns the pi3 under load - yes, the pi3 (non-plus) had some thermal concerns..

Case in point... heat sinks on the pi3+ don't help much...

If one wants to put a heat sink, drop one on the main SoC - that's all that is needed - one doesn't really need one on the USB hub chip or the pi3+ PMIC - they don't get warm enough to matter...

 

[kvic]

Case in point... heat sinks on the pi3+ don't help much...

View attachment 13922

The tests fail to report for both models the SoC is operating at max clock freq or not at its highest temperature. The SoC's will throttle to get burnt.

If one wants to put a heat sink, drop one on the main SoC - that's all that is needed - one doesn't really need one on the USB hub chip or the pi3+ PMIC - they don't get warm enough to matter...

I won't put one on the USB-Ethernet bridge chip. That was my point but that's the second largest chip on the front so I could see why people do that.

The PMIC could go as high as 125 degree C...Given a 2nd heatsink for free, I would certainly stamp on this guy.

 

[sfx2000]

The PMIC could go as high as 125 degree C...Given a 2nd heatsink for free, I would certainly stamp on this guy.

Not really needed though - even in the worst of conditions (high load, high ambient), one isn't likely to overheat this PMIC - it's not working very hard compared to other applications that it is designed for (e.g. power hungry FPGA's).