ARM64 – Pi3 Still Very Unstable..

I have tried the latest 4.7-next patched kernel, from https://github.com/anholt/linux/tree/bcm2837-64-next

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
and
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 http://rglinuxtech.com/?p=1750 ).

 ....................
 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:  http://wiki.pine64.org/index.php/Main_Page.

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:  https://github.com/apritzel/linux/tree/a64-v5.    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:  https://github.com/apritzel/u-boot/tree/pine64 , 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:  http://lkml.iu.edu/hypermail/linux/kernel/1606.0/03592.html

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 http://rglinuxtech.com/?p=1748 and http://rglinuxtech.com/?p=1750 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:    https://ask.fedoraproject.org/en/question/31666/how-do-you-install-grub2-on-a-replacement-hard-drive/

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   https://devtalk.nvidia.com/default/topic/938665/linux/linux-4-7-rc1-367-18-build-errors/

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]);
to:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 7, 0)
        gem = drm_gem_object_lookup(file, cmd->handles[0]);
#else
        gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
#endif

…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 ( http://rglinuxtech.com/?p=1746 ), 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:  https://lkml.org/lkml/2016/5/29/77

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:  https://www.mail-archive.com/u-boot@lists.denx.de/msg213468.html

=> 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: http://www.geforce.com/drivers/results/102879

Robert Gadsdon.   May 19, 2016.