Raspberry Pi 3 B+ Board Released - 3/14

[kvic]

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).

I received my shipment..

My hunch/analytic was right. My finger cannot stay for more than 5s on the main SoC as well as the PMIC for my board.

 

[sfx2000]

I received my shipment..

My hunch/analytic was right. My finger cannot stay for more than 5s on the main SoC as well as the PMIC for my board.

Again - well within range of the SoC and PMIC

Tips - get the Sandisk Extreme MicroSD cards, they work very well on this board - also make sure all packages are updated, and do the rpi-update to get the latest kernel and firmware.

Couple of scripts to help out:

pinfo.sh

#!/bin/bash
# pistuff.sh looks at firmware/kernel, and clocks, temps for gpu/cpu
# create this file in the user dir, and make it executable
celsius=$(cat /sys/class/thermal/thermal_zone0/temp | sed 's/.\{3\}$/.&/')
clock0=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq | sed 's/.\{3\}$/.&/')
clock1=$(cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq | sed 's/.\{3\}$/.&/')
clock2=$(cat /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq | sed 's/.\{3\}$/.&/')
clock3=$(cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq | sed 's/.\{3\}$/.&/')
echo "Host   => $(date) @ $(hostname)"
echo "Uptime =>$(uptime)"
echo "SW Rev => $(uname -vr)"
# VC4 stuff for RPi variants
echo "FW Rev => $(vcgencmd version)"
echo "==============="
echo "ARM Mem => $(vcgencmd get_mem arm)"
echo "GPU Mem => $(vcgencmd get_mem gpu)"
echo "==============="
echo "Pi Temp  => $(vcgencmd measure_temp)"
echo "Pi Volts => $(vcgencmd measure_volts core)"
echo "Pi Clock => $(vcgencmd measure_clock arm)"
# end VC4 stuff
# rest is from linux, should apply to any
echo "==============="
echo "ARM Temp => ${celsius} °C"
echo "Core0Clock=> ${clock0} MHz"
echo "Core1Clock=> ${clock1} MHz"
echo "Core2Clock=> ${clock2} MHz"
echo "Core3Clock=> ${clock3} MHz"
echo "==============="

and one to enable ZRAM - which is nice to keep swap off the flash... pop this over in /etc/bin/zram.sh and make it executable... then add it to /etc/rc.local

#!/bin/bash
cores=$(nproc --all)
modprobe zram num_devices=$cores

swapoff -a

totalmem=`free | grep -e "^Mem:" | awk '{print $2}'`
mem=$(( ($totalmem / $cores)* 1024 ))

core=0
while [ $core -lt $cores ]; do
  echo $mem > /sys/block/zram$core/disksize
  mkswap /dev/zram$core
  swapon -p 5 /dev/zram$core
  let core=core+1
done

And of course, map /tmp over to tmpfs on /etc/fstab

Makes for a nice little box...

Also I would rebuild the sshd_host* stuff - delete the existing ones, and do a dpkg-reconfigure openssh-server

Enjoy!

 

[sfx2000]

Good example of temps on pi3 (not the pi3b+ which runs a bit cooler) - putting it under a bit of load...

 

[kvic]

My board is not a Raspberry Pi. I'll find time to write about it later..so let's keep a little suspense for now.

Raspberry Pi community is over crowded that's good in general btw. But I don't need that. I'm more interested in server workload that a few Raspberry Pi competitors do better.

Currently my board boots up with UHS-I bus speed on the MicroSD socket. As soon as I start benchmarking, it drops back to high speed. Under such situation though, SanDisc Ultra 16GB MicroSD /w A1 moniker (the one I bought) still performs as advertised. I need to find out how to keep the bus at UHS-I..

 

[kvic]

I need to find out how to keep the bus at UHS-I..

OMG. As long as I unplug the HDMI cable (with a reboot), sdmmc retains UHS-I bus speed no matter how many times I run the benchmark...weird.

Now random 4KiB write doubles its performance with a faster bus (compared to "sd high speed"), and 33% better performance compared to in a USB 2.0 card reader. All the same card - SanDisk Ultra /w A1. I'll put up some numbers in the other thread.

EDIT:

"double its performance" is apparently wrong. After retest in Armbian, it's about 15% performance boost (UHS-I over SD High Speed).

Different firmware images are little bit messy in the SBC world. The ones provided by my vendor are particularly in need of improvement.

 

[sfx2000]

My board is not a Raspberry Pi. I'll find time to write about it later..so let's keep a little suspense for now.

Sure - the Zram.sh script isn't pi-specific, and works well with many of the SBC distro's...

Hopefully your SBC doesn't depend on MicroUSB for power (e.g. standard pin/barrel) - Pi3B/B+ pushes the limits there on that connector, and I had better luck powering the TinkerBoard via the 40 pins with a bench power supply...

I'm in suspense waiting to hear what board you picked, but my guess is either Mediatek or Rockchip based, AllWinner on the outside - I was thinking UP board first, but as soon as you mentioned Armbian

With a lot of the fruity-pi boards, I agree that the quality of the OEM supplied images is spotty - some are better than others, and AllWinner and Rockchip seem to be the SoC's of choice - AllWinner as Bootlin (formerly Free Electrons) has been pulling in linux mainline support, and Rockchip as Google's ARM SoC of choice for Chromebooks, so there's some checkin activity there because of it.

Anyways, once you've had some time on your board, feel free to open a new thread - I've been asking Tim to set up a sub-forum for SBC's and related topics, maybe even including other popular maker platforms like the ESP32/ESP8266 and Arduino things - there's interest across the SNB community for DIY internet of things development.

FWIW - Ghost runs fine as a container on Pi's - good source for info -- https://blog.alexellis.io/ghost-on-docker-5mins/

 

[kvic]

Sure - the Zram.sh script isn't pi-specific, and works well with many of the SBC distro's...

Armbian is well polished in terms of optimization. But your script will be useful to me soon. My goal is to build an image from ArchLinux for ARM. They call it ALARM..

Over the weekend, I could build vendor's u-boot / kernel. Digging further the kernel is configured as as a single pie and also lots of network functions are excluded. I want most stuff separated into loadable modules and include essential features that I get used to e.g. netfilter & etc. This will take sometime I guess. The end result perhaps will be useful to some other people.

I pick the board because its PCB layout is neat & clean. It comes with eMMC (optional), UHS-I, USB3 and a true gigabit ethernet. It shall bring me some fun for the weeks/months ahead.

 

[sfx2000]

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?

Working on something else, but what I can share is that the Cypress chipset (ex-Broadcom) is remarkable in how it behaves with 5GHz - it's very similar to iOS in how it associates with an AP, and it's beam forming and roaming feedback with 11ac and other specs.

https://pastebin.com/rT7A3srS

It's not the fastest thing out there - tops out around 100 Mbps*, give or take, but it's clean, even down to the if level, no retransmissions, unlike the USB based Ethernet interface.

* the WiFi chipset - CYW43455, it's limited by the SDIO bus, and there it's 25MBps, but it's not shared with the SDCard at least, unlike the Gbe and the USB2.0 on ethernet.

Note - The RPi's proant antenna is actually pretty good - reasonably efficient @-3.5 dB, compared to a dipole at -1.25dB, and the gain is around -0 dB - which means the pattern is pretty decent for a client. Not bad for a trace in the board at this price as it's zero cost on the BOM - most others do a PIFA, and that has it's own issues.

Rather good when someone sees the pattern - most smartphones would like to have this for WiFi and Bluetooth....

Source - http://www.embedded-computing.com/iot/a-lesson-in-wireless-engineering-from-the-raspberry-pi