X86_64 – ‘Apollo Lake’ SOC System, with a Gotcha..

After more research, I decided to get one of the Intel ‘Apollo Lake’-based SOC systems, and the one I chose was from Kodlix..     It is functionally identical with another from Beelink, and in fact the Kodlix website shows images of the Beelink version of the device..    I just preferred the Kodlix version, as the case was a dark grey, without any logos on it..

ap42

AP42

These devices all come with Windows 10 pre-loaded, and boot via UEFI, and the ‘Gotcha’ is that they will not boot with GRUB, which would appear to rule out installing most Linux distros…

I did look at the bios settings, and there would appear to be a solution, as there is an option for ‘Legacy’ boot instead of UEFI.   I tried this, and it made no difference – all you see is a blank screen, with a small flickering cursor in the top left corner..

There is a solution available, as a substitute for GRUB, which works with the AP42 UEFI, and boots Linux (and other OS’s..) – Refind ( http://www.rodsbooks.com/refind/installing.html ).

The AltLinux Rescue live cd/usb uses Refind, and I used that to examine the disk layout etc., before starting the Linux install ( https://en.altlinux.org/Rescue ).

The actual install process is similar to that for an ARM system, in that you use a rootfs disk image, and add the Refind boot manager to that.    For mine, I just cloned another x86_64 Fedora 26 system, but if you cannot do this, then there are some ‘raw’ disk images for ‘cloud’ installs, at https://dl.fedoraproject.org/pub/fedora/linux/releases/26/CloudImages/x86_64/images/ .

In short, I created a USB Fedora 26 disk image, with Refind installed, and used this to boot the AP42, then replaced the Windows 10 partitions etc. with ones for Linux/EFI:

From fdisk:

Disk /dev/mmcblk0: 58.2 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Device         Start  End       Sectors   Size  Type
/dev/mmcblk0p1 2048   206847    204800    100M  EFI System
/dev/mmcblk0p2 206848 122140671 121933824 58.1G Linux filesystem

Then I installed Refind on the EFI partition, and Fedora 26 on the Linux partition (label ‘ap42root’).    The refind config I used (created using a text editor) is as follows:

# cat /boot/efi/efi/boot/refind.conf
timeout 20
scan_all_linux_kernels false

menuentry "Fedora 4.13-rc3" {
 icon /EFI/BOOT/icons/os_fedora.png
 volume "ap42root"
 loader /boot/vmlinuz-4.13.0-rc3
 initrd /boot/initramfs-4.13.0-rc3.img
 options "root=/dev/mmcblk0p2 console-tty0 rw net.ifnames=0"
 enabled
}

menuentry "Fedora 4.12.4" {
 icon /EFI/BOOT/icons/os_fedora.png
 volume "ap42root"
 loader /boot/vmlinuz-4.12.4
 initrd /boot/initramfs-4.12.4.img
 options "root=/dev/mmcblk0p2 console=tty0 rw net.ifnames=0"
 enabled
}

I disabled the ‘scan’ function, as this created a boot option with the wrong parameters for my system..   I did try without the initrd, but the boot failed..

Detailed technical documentation for these systems is practically non-existent, even from the suppliers..    I wanted to find a UART connection, as the SOC is supposed to support one, and there is an (unpopulated) 15-pin connector on the system board, but there is no circuit diagram..

With Fedora 26, and Kernel 4.12/4.13, everything seems to work OK..    I deliberately de-configured the WiFi, as I only need a wired Ethernet connection.    The system is cooled by a large internal heatsink, and via the aluminium body, and this seems to work OK, even with an all-cpus-at-100% kernel compilation..     One nice feature is that the board includes a connector for an internal M2 SSD, but this involves opening up the case, which – presumably – would ‘void the warranty’!

Robert Gadsdon.   July 30, 2017.

Kernel – 4.13-rc2 out – Still OK with Latest VMware (patched) and NVIDIA..

Kernel 4.13-rc2 has been released, and brief details of changes from -rc1 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1707.2/06568.html

It used to be that if things were OK with the initial -rc version of the kernel, then all subsequent -rc versions were also OK, but in recent times, this has not always been the case..

I have quickly tested this with the latest NVIDIA (384.47) and VMware (12.5.7 with patched vmnet) and everything still works – the same as with -rc1..

Robert Gadsdon.  July 24, 2017.

 

VMware – Fix for Kernel 4.13-rc1 and vmnet, Already..

Thanks to fast work by dariusd at the VMware forum, there is already a fix for the vmnet compile failure with Kernel 4.13-rc1..

The patch can be found on this thread:  https://communities.vmware.com/message/2688967

I have tested it, and vmnet now compiles OK, and VMware 12.5.7 loads/runs on Kernel 4.13-rc1..

Robert Gadsdon.   July 15, 2017.

Kernel – 4.13-rc1 Released Early – OK with Latest NVIDIA, Breaks VMware..

Kernel 4.13-rc1 is out, a day earlier than usual, and brief details are here: http://lkml.iu.edu/hypermail/linux/kernel/1707.1/04719.html

The latest NVIDIA driver – 384.47 – compiles and loads OK:

 .....
Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia-drm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.47/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.13-rc1'

VMware 12.5.7 vmmon compiles OK, but vmnet fails:

....................
/home/rgadsdon/kernel/vmnet-only/bridge.c: In function ‘VNetBridgeReceiveFromVNet’:
/home/rgadsdon/kernel/vmnet-only/bridge.c:639:14: error: passing argument 1 of ‘atomic_inc’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 atomic_inc(&clone->users);
 ^
In file included from ./include/linux/atomic.h:4:0,
 from ./include/linux/rcupdate.h:38,
 from ./include/linux/rculist.h:10,
 from ./include/linux/pid.h:4,
 from ./include/linux/sched.h:13,
 from /home/rgadsdon/kernel/vmnet-only/bridge.c:25:
./arch/x86/include/asm/atomic.h:89:29: note: expected ‘atomic_t * {aka struct <anonymous> *}’ but argument is of type ‘refcount_t * {aka struct refcount_struct *}’
 static __always_inline void atomic_inc(atomic_t *v)
 ^~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:303: /home/rgadsdon/kernel/vmnet-only/bridge.o] Error 1
make[1]: *** [Makefile:1511: _module_/home/rgadsdon/kernel/vmnet-only] Error 2
make[1]: Leaving directory '/usr/src/linux-4.13-rc1'
make: *** [Makefile:120: vmnet.ko] Error 2

Robert Gadsdon.    July 15, 2017

Kernel – 4.12 Final Released – OK with Latest VMware and NVIDIA..

Kernel 4.12 is out, and brief details of changes from -rc7 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1707.0/00325.html    You can find more detailed info from the kernel git site: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.12&showmsg=1

The latest versions of VMware (12.5.7) and NVIDIA (384.47-beta and 381.22) compile and load/run OK with 4.12..

Robert Gadsdon.   July 2, 2017.

VMware – 12.5.7 Released – OK with Kernel 4.12, Still Needs GUI/GCC7 Workarounds..

VMware version 12.5.7 is out, and the release notes are here:  http://pubs.vmware.com/Release_Notes/en/workstation/12/workstation-1257-release-notes.html     As usual, not much actual detail, apart from “…some bug fixes and security updates.

This version compiles OK with Kernel 4.12 (tested with 4.12-rc6), but the runtime GUI and GCC7 workarounds mentioned in previous articles are still needed, for ‘newer’ distros, such as Fedora 26….

Robert Gadsdon.   June 22, 2017.

Fedora – Fix for Broken Kodi on Fedora 25

More distro-specific than usual posts, but hopefully ‘useful’..

I found that Kodi on Fedora 25 would no longer play M2T/MTS files.    Frustratingly, there was no error shown, or apparent debug clue, but the program just exited without any messages, when playback of one of these file types was selected.

After checking associated libraries and not getting any clues, I did find that the Fedora 26 version played everything OK, despite the fact that the version (17.3-1) was the same as F25.      This was confirmed on four different systems..

I decided to try rebuilding the kodi rpm from source, using the ‘latest’ version, from here:

http://download1.rpmfusion.org/free/fedora/development/rawhide/Everything/source/SRPMS/k/kodi-17.3-1.fc27.src.rpm

After sorting out and installing the required …devel.. rpms, the rpmbuild –rebuild on F25 completed OK, and after (force) updating with the resulting set of rpms, everything works OK again..      Slightly annoying to not have the cause of the problem, but at least this fixes it..

Robert Gadsdon.  June 18, 2017.

 

VMware – Clues for vmmon Kernel 4.12 fix?

In the thread on the VMware forum ( https://communities.vmware.com/thread/565157 ) there is a link to a potential patch for Kernel 4.12 support, but you are advised to not try to execute this, as – although it compiles OK – it will cause the host system to reboot without warning as soon as a client is started..   I have ‘tested’ this, and confirm that the host immediately reboots, without any console output!

I did mention in the earlier article that VirtualBox suffered from a similar problem, and it appears that they now have a solution ( https://www.virtualbox.org/ticket/16725 ).    To see the changes that have been made, compare the old and new versions of memobj-r0drv-linux.c in the source tree..

Hopefully a fix will be available for VMware, soon..

Robert Gadsdon.   June 9, 2017.

VMware – Simple Fix for 12.5.6 Runtime with Fedora 26

After further research, I have found a simple solution for the VMware 12.5.6 runtime, with Fedora 26, thanks to comments by ronengi and others on the Archlinux site ( https://aur.archlinux.org/packages/vmware-patch/ ).   This made sense, as the vmware-installer graphical interface still ran OK, despite the runtime vmware not doing so..

# cp -r /usr/lib/vmware-installer/2.1.0/lib/lib/libexpat.so.0 /usr/lib/vmware/lib
# cd /usr/lib/vmware/lib/libz.so.1
# mv -i libz.so.1 libz.so.1.old
# ln -s /usr/lib64/libz.so.1 .

Then just run the executable in the normal way  – # vmware

The kernel modules vmmon and vmnet still need to be manually compiled with gcc 7 and copied, as follows:

In the /usr/lib/vmware/modules/source directory, unTAR vmmon.tar and vmnet.tar, and then enter the resulting vmmon-only and vmnet-only directories and just type # make in each. Then create a /lib/modules/<kernel version>/misc directory, and copy vmmon.ko and vmnet.ko there, then # depmod -a.

I have still not found a solution for vmmon with Kernel 4.12-rc, but have reported the problem on the VMware forum..

Robert Gadsdon.   May 29, 2017

VMware – 12.5.6 Breaks Fedora 26 / GCC 7 Workaround..

I had been testing VMware 12.5.6 – unsuccessfully – with Kernel 4.12-rc2, but on reverting to Kernel 4.11.3, I found that the vmware runtime workaround for Fedora 26 / GCC 7 ( see http://rglinuxtech.com/?p=1939 ) no longer worked, and produced the same result as before the modifications – no execution, and a return to the command prompt..

After further testing, I found that the only solution was to revert to VMware 12.5.5 – with the 4.11 vmmon/vmnet patches.    The workaround was successful, again..

Fedora 26 is due to be released in about six weeks time (but may slip..) and hopefully this workaround will be unnecessary, by then..

Robert Gadsdon.   May 26, 2017.