ARM64 – Pi3 Still Very Unstable..

I have tried the latest 4.7-next patched kernel, from

After some trials, I did manage to – just – get it to boot – after falling to an ’emergency console’, but the system is very unstable, with multiple recurring MMC errors..

 Give root password for maintenance
 (or press Control-D to continue):
 Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)
 [ 714.545569] mmc0: Timeout waiting for hardware interrupt.
 [ 715.484762] mmcblk0: error -110 transferring data, sector 1026056, nr 16, cmd response 0x900, card status 0xc00
 Fedora 24 (Twenty Four)
 Kernel 4.7.0-rc3-next-20160615 on an aarch64 (ttyS0)

There appear to be two mmc drivers for the PI3 in the selection..

SDHCI platform support for the BCM2835 SD/MMC Controller
SDHCI support for the BCM2835 & iProc SD/MMC Controller

Selecting _both_ results in kernel boot with multiple mmc errors, and completes eventually, but is not stable..

Selecting just ‘SDHCI platform support for the BCM2835 SD/MMC Controller‘ gives boot fail with multiple repeating MMC errors..

 [ 21.995425] Waiting for root device /dev/mmcblk0p2...
 [ 22.787918] mmc0: problem reading SD Status register
 [ 22.923726] mmc0: error -84 whilst initialising SD card
 [ 27.649114] mmc0: error -84 whilst initialising SD card
 [ 32.397154] mmc0: error -84 whilst initialising SD card
 [ 37.129422] mmc0: error -84 whilst initialising SD card
 [ 41.861163] mmc0: error -84 whilst initialising SD card
 [ 46.581532] mmc0: error -84 whilst initialising SD card
 [ 51.313549] mmc0: error -84 whilst initialising SD card
 << repeated...>>

Selecting just ‘SDHCI support for the BCM2835 & iProc SD/MMC Controller‘ gives partial boot after an emergency console, but then repeated write failures…

 [ 2314.922231] systemd-journald[925]: Failed to write entry (27 items, 745 bytes), ignoring: Read-only file system
 [ 2315.139570] systemd-journald[925]: Failed to write entry (27 items, 749 bytes), ignoring: Read-only file system
 [ 2315.359321] systemd-journald[925]: Failed to write entry (27 items, 750 bytes), ignoring: Read-only file system
 [ 2315.577424] systemd-journald[925]: Failed to write entry (20 items, 618 bytes), ignoring: Read-only file system
 << repeated...>>

I returned to the relatively-stable 4.5.0+ kernel, but even this tombstones every so often, and usually has to be booted via the emergency console..

So – for the time being – I will wait until a more stable patched kernel is available..

Robert Gadsdon.   June 20, 2016.

NVIDIA – New Driver – Still Broken with Kernel 4.7 – Patch Fix OK..

Just tested the latest NVIDIA driver – 367.27 – and it fails to compile with Kernel 4.7-rc3.     To fix this, the patch for 367.18 still works ( details at ).

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

Robert Gadsdon.  June 13, 2016

ARM64 – Pine64 – Not Exactly ‘Compact’..

I recently obtained one of the newly-released (- to the ‘public’..) Pine64 ARM64 systems…    My first reaction, was that it is a bit on the large side..  The board is over twice the size of the Odroid C2..

Pine64 ARM64.

Pine64 ARM64.

As usual, the ‘standard’ U-Boot was a heavily-customised old version, that only mounted Android-format Kernel ‘blob’s, but a hacked version of this – which loads standard ARM64 ‘Image’ kernels, is available, and I used the one from the Debian/Longsleep image referenced on the Wiki:

I substituted a Fedora 24 aarch64 root filesystem, and everything worked OK.

Fedora 24 (Twenty Four)
Kernel 3.10.65-7-pine64-longsleep on an aarch64 (ttyS0)

I then tried the patched 4.7-rc1 kernel from here:    I found that this did boot, if the Kernel config was left unchanged after ‘make defconfig’..

Fedora 24 (Twenty Four)
Kernel 4.7.0-rc1+ on an aarch64 (ttyS0)
# uname -a
Linux rgpine 4.7.0-rc1+ #1 SMP PREEMPT Tue Jun 7 05:01:18 EDT 2016 aarch64 aarch64 aarch64 GNU/Linux

I found that the networking did not work, and so had to select this (ST Microelectronics / STMMAC / Allwinner GMAC), and this is still being tested, along with other deselections of ‘unwanted’ options..    I had originally just selected ‘Allwinner..sunxi..’ under the ‘Platform selection’ option, but this did not boot…      The aprinzel kernel is still very much work-in-progress, and there should be later versions soon..

I did try a patched version of the mainline U-Boot, from here: , and I did get it to load (boot0 plus u-boot image) and run, but the resulting kernel boot (using a known/good kernel) was unsuccessful…

[ 160.236247] platform reg-81x-cs-rtc: Driver reg-81x-cs-rtc requests probe deferral
[ 160.245014] platform reg-81x-cs-aldo1: Driver reg-81x-cs-aldo1 requests probe deferral
[ 160.254129] platform reg-81x-cs-aldo2: Driver reg-81x-cs-aldo2 requests probe deferral
[ 160.263626] platform reg-81x-cs-aldo3: Driver reg-81x-cs-aldo3 requests probe deferral
[ 160.272743] platform reg-81x-cs-dldo1: Driver reg-81x-cs-dldo1 requests probe deferral
[ 160.281947] platform reg-81x-cs-dldo2: Driver reg-81x-cs-dldo2 requests probe deferral
[ 160.291064] platform reg-81x-cs-dldo3: Driver reg-81x-cs-dldo3 requests probe deferral
[ 160.300165] platform reg-81x-cs-dldo4: Driver reg-81x-cs-dldo4 requests probe deferral
[ 160.309310] platform reg-81x-cs-eldo1: Driver reg-81x-cs-eldo1 requests probe deferral
[ 160.318427] platform reg-81x-cs-eldo2: Driver reg-81x-cs-eldo2 requests probe deferral
................. etc...........etc................

One other thing to watch..   I did get the wifi/bluetooth plug-on daughter board, but this became extremely hot, after a short while, and I removed it..

Robert Gadsdon.   January 7, 2016.

Kernel – 4.7-rc2 Released – rc1 Patches Still Work.

Kernel 4.7-rc2 is out and brief details of changes from -rc1 are here:

After all the later-rc breakage with 4.6, I tested the latest patched NVIDIA drivers, and VMware, with this version, and all the previous 4.6/4.7 patches for VMware 12.1.1, and the 4.7 patches for NVIDIA 367.18 and 361.45.11 still work.   See and for details..

Robert Gadsdon.  June 5, 2016.


Hardware – Replacing the System Disk..

My ‘system disk’ (/dev/sda) started to show bad sectors, recently, and so I decided to replace it.    The disk was around 8 years old, and had been in almost-continuous use..

I have not had to do this for some considerable time, and I think the last time was in the late-90s, and using LILO!  (No convoluted grub2 commands and UUIDs back then..)

I found – after some trials – that one successful way of doing this is mentioned in an article here, and thanks to Arif for the information:

I created a (Fedora 23) netinst image on a USB stick, and booted from this, and ran the ‘rescue’ utility…    The system only had a USB2 connection, so the utility was very sluggish, but I found that I could get a command prompt by typing alt/tab.. I mounted the ‘new’ root partition (/dev/sda2) under /mnt/sysimage (/run/media/liveuser/newdiskroot in the example), and mounted the (separate) boot partition (/dev/sda1) under /mnt/sysimage/boot..    I had decided to use btrfs for the ‘new’ root partition, but – being over-cautious – kept the boot partition as ext4..

After running the (modified) commands mentioned in the article – and remembering to update /etc/fstab – the system booted correctly..

This is – of course – rather Fedora-specific, but it is possible to get dracut on other Distros..

Robert Gadsdon.   June 2, 2016.


NVIDIA – Possible Kernel 4.7 Fix for 361.45.11 and 367.18..

Thanks to juston_li on the NVIDIA Devtalk forum, there is specific detail of the changes needed for Kernel 4.7 compatibility..

Details are at

The first issue is interesting, as it is due to a Kernel Dev. deciding to introduce a new variable – radix_tree_empty – in Kernel 4.7-rc1, that happens to have the same name as one already used by NVIDIA..     Rather than change Kernel code, I decided to change the NVIDIA variable name instead..

So..  In NVxxxx/kernel/nvidia-uvm/uvm8_gpu.c and NVxxxx/kernel/nvidia-uvm/uvm_linux.h I changed the variable name from radix_tree_empty to radix_tree_is_empty

There was some concern that changing the NVIDIA code may affect some of their binary executables, but I have tested this modification on a live system, and it all appears to work OK..

For driver 361.45.11, this is the only change needed, as this driver does not include any of the nvidia-drm code.

For driver 367.18 and Kernel 4.7, the changes to remove the (redundant) dev parameter, as shown in the article, are also necessary, and these need to be kernel-version dependant if the driver will also be run on Kernel 4.6 and earlier..    To enable the kernel version test to occur, I had to add #include <linux/version.h> to both nvidia-drm-fb.c and nvidia-drm-gem.c..

As an example, for nvidia-drm-fb.c  I changed the code around line 113 from:

        gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
        gem = drm_gem_object_lookup(file, cmd->handles[0]);
        gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);

…and made the same change to nvidia-drm-gem.c, around line 408..

With these changes, both drivers compiled/loaded OK with Kernel 4.7-rc1, and 4.6.0..

Robert Gadsdon.   May 30, 2016.

VMware – Possible Kernel 4.7 Fix for 12.1.1..

Thanks to g, from their comment on my previous article ( ), there may be a more correct vmnet fix than simply ‘commenting out the code’..    Replace dev->trans_start = jiffies with  netif_trans_update(dev) in netif.c

I have made this change, and VMware 12.1.1 is – so far – loading and running OK, as usual..

Robert Gadsdon.   May 30, 2016.

Kernel – 4.7-rc1 Breaks NVIDIA and VMware..

Kernel 4.7-rc1 is out, and brief details are here:

The update breaks the latest NVIDIA drivers – 367.18 and 361.45.11:

/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-uvm/uvm_linux.h:557:13: error: redefinition of ‘radix_tree_empty’
 static bool radix_tree_empty(struct radix_tree_root *tree)
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-drm/nvidia-drm-gem.c: In function ‘nvidia_drm_dumb_map_offset’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-drm/nvidia-drm-gem.c:411:33: error: passing argument 1 of ‘drm_gem_object_lookup’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 gem = drm_gem_object_lookup(dev, file, handle);

..and, breaks 4.6-patched VMware 12.1.1 (vmnet):

/tmp/modconfig-UkXRB7/vmnet-only/netif.c: In function ‘VNetNetifStartXmit’:
/tmp/modconfig-UkXRB7/vmnet-only/netif.c:468:7: error: ‘struct net_device’ has no member named ‘trans_start’
 dev->trans_start = jiffies;

I tested the vmnet issue by simply commenting out the line dev->trans_start = jiffies in netif.c, and VMware then compiled and (apparently..) ran OK..    This is not a proper solution, though!

Robert Gadsdon.   May 29, 2016

ARM64 – Odroid C2 U-Boot – More Progress..

Thanks to an additional U-Boot patch from Carlo Caione, it is now possible to (partially) boot the mainline Kernel from U-Boot on an eMMC module, as well as from SDcard..    Patch details here:

=> mmc info
Device: <NULL>
Manufacturer ID: 15
OEM: 100
Name: BGND3
Tran Speed: 52000000
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 29.1 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 29.1 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
=> mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID         Type
 1   2048         56973312    d3630000-01   83
 2   56975360     4096000     d3630000-02   82

As I mentioned in an earlier article, it is not -yet – possible to boot the Kernel all the way from MMC devices, as support is not in the current (May 22) version of Linux-Next..

Robert Gadsdon.    May 22, 2016.

NVIDIA – Driver 367.18 – OK with Kernel 4.6..

Tested the latest NVIDIA ‘Beta’ driver – 367.18 – and it compiles OK with Kernel 4.6..

Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-drm.ko
 CC /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/Desktop/Downloads/NVIDIA-Linux-x86_64-367.18/kernel/nvidia.ko

Release notes etc. are here:

Robert Gadsdon.   May 19, 2016.