blood

On a rockpi 4 I found that switching from lz4 to gz by itself didn't make much of a difference, but disabling compressed indices altogether in /etc/apt/apt.conf.d/02-armbian-compress-indexes and deleting all the lz4 and gz files from /var/lib/apt/lists/ did the trick for me. I'll happily give up a bit of disk space for the interactive performance for now. I didn't dig into the code yet (and maybe this is already obvious to some) but I suspect this is a mix of unoptimized code paths when dealing with compressed files as well as maybe differences in instruction set extentions between systems. With the default buster settings, this slow behavior occurs on all my arm systems except for a clearfog base which has the notable differences of not being aarch64 and including some handy instruction set extensions that aren't always present on other boards: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 When I strace one of the "search" operations, I see a pattern that just doesn't look right... I see lots of repeated "openat" syscalls for the same files over and over along with "reads" for the same blocks of data. Over time, the reads expand to read additional data - but they always follow reading the same data over and over again. It smells to me like whatever method is being used by apt to iterate through these compressed files is resulting in some _very_ inefficient file access patterns. None of this translates to any noticeable hit on the disks because the filesystem cache works well and so all you see is user cpu thrashing one core. I'll be surprised if there isn't a way to avoid the pattern that I'm observing that would clean this up considerably and hopefully I'll have time to help figure it out.

I understand that this board is unsupported so I'm not expecting much, but I have one of them and tried it out last night after yanking my eMMC and flashing to an SD card. Things seem to work OK, but I did notice that the load average idles around 1.0 with nothing visibly using any CPU time. I did notice that a kworker process is in uninterruptible sleep. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 132 0.0 0.0 0 0 ? D 10:31 0:00 [kworker/3:1+events_freezable] I uploaded an armbianmonitor dump in case it shows anything. http://ix.io/2Ubq It seems this board isn't aging well - the eMMC doesn't work with mainline kernels, the BSP kernels seem to be quite old, USB troubles, serial console only (though that's all I want to use). It's a shame, as it served me well for a long time (albeit with an older BSP kernel). Perhaps it's not worth messing with these any more and I should retire it?

I bought a Clearfog Base shortly after they came out and have been running Armbian on it since early on as my home router. In general this is a solid SBC for a home router and light weight server. 2 x gigabit copper NICs, and an SFP cage - nothing dangling off USB here m.2 SATA storage - about the best support for performant storage of any SBC I know of; m.2 SATA leaves eMMC and SD in the dust. It's not NVMe, but for this little box, it's great. 1GB of memory - this is enough to run a few containers for light weight services like caching DNS and DHCP USB console - rather than exposing a UART on a few GPIO pins, this includes an authentic FTDI chip so all you have to do is plug it into another system's USB port and fire up picocom to get OOB management mPCIe slot - I haven't ever used this, but it's there if I wanted to It simply sips power. Seriously, just a few watts. Passively cooled, though I plugged in a small 5v fan off the gpio headers just to be nice to it When it first launched, I had a bit of trouble getting anything after the first NIC working, but a bit of hackery with the device tree got the second copper port working easily enough. Getting it to boot off m.2 was also problematic at first, but someone figured that out, and wrote a nice doc. I sorta forgot about the SFP cage because the initial kernels didn't support it - but more on that later. For the most part, once I got it up and running I locked it down with a tight firewall policy and let it do its thing and it gave me zero trouble for over 1000 days. That said, I let it languish a bit and now that Buster is nice and stable, I found myself wanting some of what it had to offer - but I dreaded taking it down since it was my Internet gateway, and my ISP is finicky about other routers getting DHCP leases from the WAN with different MACs. But I took the plunge a few days ago and reflashed to a fresh and modern copy of Armbian Buster and I'm really glad that I did... For one, the mainline kernel support has really come a long way! Now the SFP cage works - and I am beyond happy that I am able to use it with 4g optics (I think from an old fiberchannel rig) to get a 2.5gbe link up between it and my ES-16-XG switch. For an older board, this was such a welcome discovery that I can't see myself replacing it for years to come. Secondly, Armbian Buster is a nice operating system. I converted my iptables ruleset to nftables without much fuss. In Jessie and Stretch, I had a pretty hacked together IPv6 setup using isc-dhcp-client, requiring a bunch of kludgy scripting to get delegation working properly - but now I am receiving a /60 of address space using wide-dhcpv6-client that I then advertise as /64s on a few VLANs with radvd, and stuff is working with so much less fuss. Buster itself has packages for some nice tools that I always had to build myself before (like exa). Lastly, I haven't done it yet, but I'm stoked to start using wireguard for remote access and that should be much less trouble than before the upgrade. So yeah, for whatever reason there aren't that many arm SBCs that are all that well suited to being routers. Sure, you can do it one-armed with VLAN tags on a lot of systems, but they tend to have crappy storage and baggage from poorly supported video hardware that I don't even want to use. Clearfog Base has been legit for a while, and it seems to be getting better still. To everyone that contributed to making Armbian run well on this board, thanks!

For what it's worth, a Debian 9 image for this board was posted recently and is available at: http://share.loverpi.com/board/libre-computer-project/libre-computer-board-roc-rk3328-cc/image/debian/ I just threw it on an eMMC and booted up my board and it's working nicely now - though I'd prefer Armbian all the same. Since it's on my mind, I don't understand why they (Libre? Firefly? Rockchip?) chose 1.5mbps as the baud rate for the serial port. The only thing I can get to work with it is minicom and specifically minicom on Linux - on my MBP it won't let me use that speed, and even on Linux ckermit refuses to go that fast as well. It's a console... why not use a compatible speed? Also, not burning in a MAC address is lame too. I managed to get around that at least. On a positive note, I uninstalled network manager and lightdm and now it boots soup-to-nuts in under 10s.

I bought one of these too after the project reported that they'd be supporting Armbian. It arrived last week. I did try to boot the rock64 armbian image on it but didn't have much success: Starting kernel ... <hit enter to activate fiq debugger> Loading, please wait... starting version 229 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block .... Begin: Running /scripts/local-block ... done. That last line then repeats a bunch of times and it reboots in a loop like that. All things considered I'm used to these sorts of boards shipping with terrible support (not throwing shade at Armbian; you guys rock - it's the vendors' fault) so I won't say I'm surprised or even disappointed. I'm not sure whether their promise of Armbian support was an assumption that this project would pick up their slack, or if they were actually going to contribute such support. Any news on how/if this is progressing?

On my Clearfog Base, I noticed that the temperature reported in motd was different than that reported by /sys/devices/virtual/thermal/thermal_zone0/temp - and reading the script at /etc/update-motd.d/30-sysinfo I found towards the end a comment about readings being done on the heatsink for Marvell systems (of which this is one), and the code subtracts 30 degrees Celsius from the reading. I searched around and couldn't find any other mentions of needing to do that. I guess I'm curious how it was determined that this was necessary - and how accurate it actually should be. It seems like a questionable assumption that the sensor would report a temperature that was always a constant 30 degrees too hot - but if this is the only sensor we have I get that it's better than nothing.

I think I found a workaround for this. Is there a way to make the existing Clearfog images handle both boards? Should there be distinct images for the Base and Pro versions of the Clearfog boards?

I'm running into a problem using the second interface with my Clearfog Base. I don't have an SFP to test the third interface, but the first works fine, though the second does not. I've tried images with 3.x and 4.x kernels from both SolidRun and Armbian and they all have the same behavior. My first concern is whether this has worked for anyone else so that I can rule out faulty hardware. Can anyone chime in with whether they've successfully used the 2nd copper interface on a Clearfog Base? If so, did it work out of the box, or did it require any extra steps? Next, can someone more familiar with ARM SOCs and device trees comment as to whether the same device tree for the Pro should work for the Base? In case it helps, here is some output I cherry-picked from the boot sequence that seems related to the NICs: Board configuration detected: Net: | port | Interface | PHY address | |--------|-----------|--------------| | egiga0 | RGMII | 0x00 | | egiga1 | SGMII | In-Band | | egiga2 | SGMII | In-Band | egiga0 [PRIME], egiga1, egiga2 | Lane # | Speed| Type | ------------------------------| | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 | ------------------------------- PCIe, Idx 1: detected no link PCIe, Idx 2: detected no link High speed PHY - Ended Successfully DDR3 Training Sequence - Ver TIP-1.39.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED SoC: model = 0x6828, revision = 0x4 mvPncVirtBase = 0xf0400000, pncTcamSize = 1024 o 3 Giga ports supported o SKB recycle supported for SWF (Disabled) o NETA acceleration mode 4 o BM supported for CPU: 4 BM pools o PnC supported (Enabled) o RX Queue support: 8 Queues * 256 Descriptors o TX Queue support: 8 Queues * 532 Descriptors o GSO supported o GRO supported o Receive checksum offload supported o Transmit checksum offload supported o Driver ERROR statistics enabled o Driver INFO statistics enabled o Driver DEBUG statistics enabled port #0: is_sgmii=0, is_rgmii=1, phy_addr=0 o Loading network interface(s) for port #0: cpu_mask=0x3, tx_csum_limit=9800 o Port 0 is connected to Linux netdevice o eth0, ifindex = 3, GbE port = 0 giga p=0: mtu=1500, mac=00:50:43:02:02:01 (platform) port #1: is_sgmii=1, is_rgmii=0, phy_addr=-1 o Loading network interface(s) for port #1: cpu_mask=0x3, tx_csum_limit=2048 o Port 1 is connected to Linux netdevice o eth1, ifindex = 4, GbE port = 1 giga p=1: mtu=1500, mac=00:50:43:02:02:02 (platform) port #2: is_sgmii=1, is_rgmii=0, phy_addr=-1 o Loading network interface(s) for port #2: cpu_mask=0x3, tx_csum_limit=2048 o Port 2 is connected to Linux netdevice o eth2, ifindex = 5, GbE port = 2 giga p=2: mtu=1500, mac=00:50:43:02:02:03 (platform) libphy: orion_mdio_bus: probed