• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Linux 18.10 (and a bit of 18.04) experience and workarounds
Here's what I have learned doing current versions of Linux on the 2g/32g Z83 board recently received.

For context, my application is an embedded system inside a piano, which has a touch screen (only) as well as connection to a midi input/output, and using wifi. 

1) Previously I used Ubuntu Mate 16.04, but Ubuntu Mate no longer works (as of 18.04) with the OnBoard keyboard and a touch screen (only).  See https://bugs.launchpad.net/ubuntu-mate/+bug/1792787. This has nothing to do with this board, other than it being rather ideal for kiosk type applications that might have a touchscreen.  This is not fixed in 18.10 either.  Sadly Ubuntu Mate and OnBoard appeared to be the best alternative -- Ubuntu (plain) has an on screen keyboard that is just awful, but is usable.

The rest of this is about Ubuntu (not Ubuntu Mate or other variations, just plain, AMP 64bit). 

2) Reinstallations will reset the hard disk boot priority in EFI, at least sometimes. The EFI OS will go back to the top, and you need to get into bios and put the hard disk itself on top. I also found EFI hard to get into, just hit F7 a lot (and for reasons unclear it seems easier if you alternate with escape).  I also found doing testing worked much easier setting the default to boot from USB - with no USB it books hard disk.

3) In Ubuntu 18.10 the sound issues in the bytcr-rt5651 (especially conflict with the HDMI sound) that were referred to all around this forum seem to be fixed. With a clean install I get stereo sound on the headset, stereo sound on the HDMI speakers, with no special changes. Since there's no separate speaker jack I did not test what happens there (it shows as a separate device now, not a profile). I found no need to blacklist snd_hdmi_lpe_audio. So rather than the special OS builds here, consider trying the distro 18.10 itself.

4) The brcmfmac43455 wifi is a real pain, and in my opinion is not reliable and may be enough to make one discard this board for Linux. Here is the closest I can get.

4a) Finally, dmesg is showing a blob missing.  I found one, installed it, and the error goes away, but I cannot see any difference in behavior with or without.  Here's where you can get it if you want it (I know nothing about this developer, I just found a file of about the right size and name, that is accepted at boot, use at your own risk, but for me it did no harm). 

        cd ~
        git clone https://github.com/armbian/firmware.git
        sudo cp ~/firmware/brcm/brcmfmac43455-sdio.clm_blob /lib/firmware/brcm/

Note this is where it goes for ubuntu 18.10, check for other versions.

4b) I used the profile (brcmfmac43455-sdio.txt) provided here http://www.minisforum.com/showthread.php?tid=125, changed the mac address and region code (at the bottom). In addition you need to: 

sudo apt install git bcmwl-kernel-source
sudo sed -i 's!blacklist brcmfmac!#blacklist brcmfmac!g' /etc/modprobe.d/blacklist-bcm43.conf
sudo modprobe brcmfmac

4c) As a side note, the Ubuntu 18.10 settings are screwed up. The power management settings to permit power control are tightly linked to the switch on the Wifi panel that enables or disables the device. You should turn all those on -- the device itself, as well as the option to let the O/S control the device (even though you might not want that). Otherwise you get "rfkill" blocks (soft blocks). 

4d) This is not itself adequate, at least not usually. The card often comes up just plain not working, but mostly from a soft reboot (i.e. without removing power). Many/most times you can fix it by, having done the above (and appropriately set up netplan/networkd/netmanager as needed) then shutdown with power off, remove the power plug, wait a few seconds and plug back in. Do not just power up with the switch, actually unplug it.

4e) As a partial workaround to reboots that might not other wise work (or work timely), I've found it useful to create a crontab (root) job that runs this script on reboot, which loops a a few times trying to unblock and bring up the link. It exits immediately if already up so it is OK to run even when it is working.  This will also attempt to clear soft blocks.  But... when all else fails, pull the plug, and power cycle.

#!/usr/bin/env bash
while [ $COUNTER -lt $MAX ]; do
    echo "Beginning loop $COUNTER of $MAX"
    STATUS="$(ip link show $DEVICE)"
    echo "    Current status return=$STATUS"
    if [[ $STATUS == *"state DOWN"* ]]; then
        echo "    Showing down, going to force unblock and force up"
        rfkill unblock all
        ip link set $DEVICE up
        echo "    Waiting 10 seconds to check again"
        sleep 10
        echo "    Now showing up - exiting"
echo "Showing current status of all network devices"
ip addr

5) Once you get past all that, if you are using a touch screen, Ubuntu 18.10 is very flakey.  The doc's button to pull up the applications is just messed up, you have to experiment to find the right keystrokes.  Try putting any apps you need as favorites, the favorite screen seems to work.  More info here: https://bugs.launchpad.net/ubuntu/+sourc...ug/1725384

6) If you have an HDMI Touch screen and are in an X11 session, and you use an idle timeout to blank the screen (NOT to sleep the processor), then you cannot wake it up with a touch to the screen. If you switch to wayland this goes away (but it trades an inability to get rid of the screen saver, and maybe other problems that wayland, being so new, may bring).  See https://unix.stackexchange.com/questions...untu-18-10

7) If you set the board to boot on power up, other events will cause a boot (I am not sure if this is only with boot on power, that is just how I have it). In particular, if you shut down with power off, then remove or replace some USB or HDMI cables, the processor begins to boot unexpectedly.  Best to simply unplug it.

8) I could not get this to work with a HDMI to DVI-D adapter at all (yet the rPi works fine on the same hardware). I do not know why, but I almost sent it back, then tried it on a regular HD TV and it worked.  You need a real HDMI display (and I suspect it must be only HD -- not sure what a 4K version would do, if it would auto-set or not). I did not try VGA.

9) On the good side: The 2gb/32GB is more than adequate for an embedded application and is very affordable; I have all of QT5 on mine including a build environment and am still at only 6.2G used, and while memory is a bit tight it can build a fairly large QT5 application without problems.  I have had no thermal issues. The audio is of adequate quality that the audio-encoded MIDI works properly (a definite problem on the rPI that required a separate USB audio device). 

Bottom line: This device runs Ubuntu 18.10 quite nicely, especially if you have a wired connection. I found no issues with the wired ethernet at all. But if you are relying on wifi, you might want to reconsider, especially if the board is used for embedded applications that make it difficult to power cycle.  I also would be concerned about higher resolution displays, and find out if they will be supported (especially during boot/bios). 


Forum Jump:

Users browsing this thread: 1 Guest(s)