Open geerlingguy opened 3 months ago
Reading through the Lichee Console 4A Wiki, there are a few important notes:
Charging is interesting—it seems like the circuit is somewhat simple, loading up the battery at the beginning and exponentially decaying over time. The unit got quite hot right after I plugged it in, which is a little alarming as I tend to trust these devkit-style devices less when it comes to thermals...
As with Milk-V Mars CM (see #22), some of the Phoronix test suites are failing:
Phoronix Test Suite v10.8.4
Installed: pts/timed-audio-encode-1.0.1
To Install: pts/encode-mp3-1.7.4
Determining File Requirements ..................................................................................
Searching Download Caches ......................................................................................
1 Test To Install
5MB Of Disk Space Is Needed
5 Seconds Estimated Install Time
pts/encode-mp3-1.7.4:
Test Installation 1 of 1
1 File Needed [1.45 MB / 1 Minute]
File Found: lame-3.100.tar.gz [1.45MB]
Approximate Install Size: 5 MB
Estimated Install Time: 5 Seconds
Installing Test @ 02:15:47
The installer exited with a non-zero exit status.
ERROR: cannot guess build type; you must specify one
LOG: /var/lib/phoronix-test-suite/installed-tests/pts/encode-mp3-1.7.4/install-failed.log
Not sure if the test suite has a risc-v option available; it works on x86 and arm64 at least.
Opened issue to check into it here: https://github.com/phoronix-test-suite/test-profiles/issues/306
Similarly, x264 install fails:
Phoronix Test Suite v10.8.4
To Install: pts/x264-2.7.0
Determining File Requirements ..................................................................................
Searching Download Caches ......................................................................................
1 Test To Install
2600MB Of Disk Space Is Needed
18 Minutes, 42 Seconds Estimated Install Time
pts/x264-2.7.0:
Test Installation 1 of 1
3 Files Needed [3321 MB / 7 Minutes]
File Found: x264-git-20220222.tar.bz2 [0.74MB]
File Found: Bosphorus_1920x1080_120fps_420_8bit_YUV_Y4M.7z [646MB]
File Found: Bosphorus_3840x2160_120fps_420_8bit_YUV_Y4M.7z [2675MB]
Approximate Install Size: 2600 MB
Estimated Install Time: 18 Minutes, 42 Seconds
Installing Test @ 02:16:03
The installer exited with a non-zero exit status.
ERROR: Makefile:3: config.mak: No such file or directory
LOG: /var/lib/phoronix-test-suite/installed-tests/pts/x264-2.7.0/install-failed.log
In terms of games:
supertuxkart
: it's competent at supertuxkart
, getting 30-40 fps at 1024x768 resolution. For some reason I was unable to switch resolutions or play full screen—any time I tried, it quit out of the game. I had to play with no blur or vsync, but it was perfectly playable on the keyboard since it's a keyboard-only game.dsda-doom
: Classic Doom but with freedoom
resources, if I try OpenGL rendering, it crashes, but software rendering works a treat. It worked in all resolutions, and plays well—excepting the atrocious RedPoint control; it was excruciating trying to use that as a mouse. Better to plug in an external mouse if you want to frag some enemies.If you want run some software with OpenGL, please try switch first: sudo switch-gl gl4es USB-C charging: It not support PD fast chraging, only can be charging with normal 5V2A (this feature is added temporarily, so it is not perfect) Sometimes (rarely) keyboard not responding, you can try press Pow+Z to restart keyboard. Temporarily, do not apt upgrade, it will upgrade the kernel and case boot error(upstream is debugging the sleep mode, buggy now...)
@Zepan - Thanks! I definitely skipped running any apt upgrades — I know for earlier hardware, it can be a bit hit or miss what packages might not yet be fully validated, so I generally run all my tests with what ships initially.
Good to know on the USB-C charging, I'll test 2A charging and confirm that's working okay.
I can confirm if I plug in USB-C power, it seems to be charging the battery off there, pulling around 2.4A at 5V with the Raspberry Pi USB-C charger. I noticed it doesn't seem to charge while the power on the device is off. It lit up the little blue LED and pulled down 2.4A momentarily, but then stopped. It only pulled any power through USB-C while powered on.
The other charger seemed to be able to charge even while the device is powered off.
With the 12v 2A AC adapter, it puts out 28W while the device is running and charging the battery (from about 70%), and then around 20W while the device is powered off. So it looks like it'll run off the wall wart while charging the battery, adding on that extra 8W or so.
@Zepan - for USB-C, is it supposed to charge the battery while powered off? I know a few other people said "USB-C charging doesn't work", but maybe it works while powered on, but not powered off?
I tried installing a SKhynix 2242 256 GB NVMe SSD in the expansion slot on the bottom, but unfortunately (a) it was very difficult to install, as it is fairly deep in the case, and the WiFi antenna cable interfered with the install, and (b) I couldn't get it seated perfectly, as there was a screw pillar inside just barely touching the side of the SSD as I inserted it.
I booted it up anyway, since I could get it about 90% of the way in the slot, but it didn't enumerate on the PCIe bus nor show up in lsblk
:
sipeed@lpi4a12d6:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 116.5G 0 disk
├─mmcblk0p1 179:1 0 2M 0 part
├─mmcblk0p2 179:2 0 500M 0 part /boot
└─mmcblk0p3 179:3 0 116G 0 part /
mmcblk0boot0 179:8 0 4M 1 disk
mmcblk0boot1 179:16 0 4M 1 disk
sipeed@lpi4a12d6:~$ lspci
sipeed@lpi4a12d6:~$ sudo lspci -vvvv
I then tried to take off the bottom, to see if I could make it fit better without the bottom cover in place, but four of the six bottom cover screws were stripped already. I hadn't attempted to use them before, so this was how they came from the factory—one was completely rounded out, and three were rounded out enough I couldn't get any purchase from any of my precision drivers (I was just barely twisting them, with no pressure, and the driver would just spin).
I've heard other reviewers have trouble with the soft screw heads too (example), but mine were pre-stripped out of the box :(
I'll have to see if I can find a screw extractor bit small enough for these tiny screws, or mangle them up with my Dremel maybe :/
My screw extractor set has bits far too large for these tiny screws, so I bought this Moody 6-piece set on Amazon, and I'll see if I can get enough purchase to pull out the screws. I'll have to dig around to find replacement screws—these guys are quite small!
I was testing Bluetooth... and it didn't seem to initialize the Bluetooth adapter. I get an error from blueman-manager
:
Connection to BlueZ failed
Bluez daemon is not running, blueman-manager cannot continue. This probably means that there were no Bluetooth adapters detected or Bluetooth daemon was not started.
hcitool dev
returns no Devices, and hciconfig -a
returns nothing.
I started the bluetooth service (sudo systemctl start bluetooth
), and that seemed to go okay, with no warnings in dmesg
, but when I opened Bluetooth Adapters or Bluetooth Manager they'd just briefly start to draw the window then crash out.
New video: https://www.youtube.com/watch?v=8qDGV6LTOnk
I also got the tiny screw extraction set, so hopefully I can get inside today...
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0
): 9.3 Wtop500
HPL benchmark: 8.5 WDisk
128 GB built-in eMMC
curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bash
Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with
curl -o disk-benchmark.sh [URL_HERE]
and runsudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh
(assuming the device issda
).PiBenchmarks.com result (TODO_INSERT_LINK_HERE):
Network
iperf3
results:Built-in Ethernet
iperf3 -c $SERVER_IP
: 943 Mbpsiperf3 --reverse -c $SERVER_IP
: 931 Mbpsiperf3 --bidir -c $SERVER_IP
: 873 Mbps up, 199 Mbps downBuilt-in WiFi
iperf3 -c $SERVER_IP
: 102 Mbpsiperf3 --reverse -c $SERVER_IP
: 110 Mbpsiperf3 --bidir -c $SERVER_IP
: 55 Mbps up, 27 Mbps down(Be sure to test all interfaces, noting any that are non-functional.)
GPU
GLMark2 ES2 Result:
The power consumption on the device jumped to 9.1W during the OpenGL tests. A tiny bit higher than the average CPU consumption during Geekbench tests.
Memory
tinymembench
results:Click to expand memory benchmark result
``` tinymembench v0.4.10 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 3141.5 MB/s C copy backwards (32 byte blocks) : 1359.6 MB/s (1.1%) C copy backwards (64 byte blocks) : 1339.0 MB/s (0.2%) C copy : 3214.8 MB/s C copy prefetched (32 bytes step) : 3227.4 MB/s C copy prefetched (64 bytes step) : 3229.1 MB/s C 2-pass copy : 2758.9 MB/s (0.1%) C 2-pass copy prefetched (32 bytes step) : 2712.3 MB/s C 2-pass copy prefetched (64 bytes step) : 2702.4 MB/s (0.2%) C fill : 11232.6 MB/s C fill (shuffle within 16 byte blocks) : 11228.5 MB/s (0.7%) C fill (shuffle within 32 byte blocks) : 1592.7 MB/s (0.2%) C fill (shuffle within 64 byte blocks) : 1592.2 MB/s --- standard memcpy : 3216.6 MB/s standard memset : 11227.0 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 0.1 ns / 0.1 ns 131072 : 17.3 ns / 26.3 ns 262144 : 26.1 ns / 34.1 ns 524288 : 32.4 ns / 39.0 ns 1048576 : 49.0 ns / 61.9 ns 2097152 : 97.0 ns / 131.3 ns 4194304 : 123.3 ns / 153.5 ns 8388608 : 147.7 ns / 181.1 ns 16777216 : 165.3 ns / 203.4 ns 33554432 : 180.7 ns / 227.0 ns 67108864 : 194.6 ns / 250.8 ns ```sbc-bench
resultsRun sbc-bench and paste a link to the results here: https://sprunge.us/fUCnrY
Phoronix Test Suite
Results from pi-general-benchmark.sh: