Kernel – 4.6-rc6 – Still OK with (Patched) VMware and NVIDIA..

Kernel 4.6-rc6 has been released, and details of changes since -rc5 are here:

It seems that there will be (at least..) an rc7, before ‘Final’..

Tested with patched VMware 12.1.0 (vmnet and vmmon) and patched NVIDIA (364.19) and both still compile OK..   See my previous article for more info..

Robert Gadsdon.    May 2, 2016.


ARM64 – Odroid C2 With Latest U-Boot and Kernel – Not Quite Yet..

I decided to check the latest linux-next tree for signs of Odroid C2 code, and there is some there – apparently for basic functionality..     Compiled OK, but when I tried to boot it, the Hardkernel-supplied version of U-Boot crashed:

odroidc2#ext4load mmc 0:1 ${loadaddr} /boot/uboot/Image
7748608 bytes read in 187 ms (39.5 MiB/s)
odroidc2#ext4load mmc 0:1 ${dtb_loadaddr} /boot/uboot/meson-gxbb-odroidc2.dtb
27913 bytes read in 5 ms (5.3 MiB/s)
odroidc2#booti ${loadaddr} - ${dtb_loadaddr}
"Synchronous Abort" handler, esr 0x96000010
ELR: 77f4b734
LR: 77f4b728
x0 : 0000000077fa6c48 x1 : 0000000000080000
x2 : 000000000079b000 x3 : 000000000079b000
x4 : 000000000000006e x5 : 0000000011000000
x6 : 0000000077fa6b08 x7 : 0000000000000044
x8 : 0000000077f9a280 x9 : 0000000000000000
x10: 0000000073f386d8 x11: 0000000077f87000
x12: 000000000000000f x13: 0000000000000000
x14: 0000000000000000 x15: 0000000000000000
x16: 0000000000000000 x17: 0000000000000000
x18: 0000000073f38e28 x19: 0000000077fa6b08
x20: 0000000011000000 x21: 0000000073f3e6c0
x22: 0000000000000003 x23: 0000000073f3e6c8
x24: 0000000000000000 x25: 0000000077f9c2c0
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000000000 x29: 0000000073f38940

I then searched for a more ‘mainline’ version of U-Boot for the C2 and found some fairly recent patches mentioned here:

I created a patch (from the original newsgroup version of the message, rather than the – mangled – web text) and applied it to the latest -rc version of U-Boot..

After commenting out a reference to psci_system_reset that – as far as I could tell – no longer existed in the U-Boot code tree, I successfully compiled u-boot.bin, and – together with the sd_fuse Hardkernel binary content – installed it on the C2.

I tried to start the device, but got a constant stream of resets:

Board ID = 8
set vcck to 1100 mv
set vddee to 1050 mv
CPU clk: 1536MHz
DDR channel setting: DDR0 Rank0+1 same
DDR0: 2048MB(auto) @ 912MHz(2T)-13
DataBus test pass!
AddrBus test pass!
Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x000000b0
aml log : SIG CHK : 351 for address 0x01700000
 ( line repeated.. )

So… There is ‘mainline’ support for the C2 coming, but not quite there yet..

Robert Gadsdon   April 26, 2016.

ARM – Another Source for Rootfs Images..

If you need a particular rootfs for an ARM7 or ARM64 device, there is a source of these at

As an example, for Fedora 23 aarch64, then download the file, and then expand it (I use ark..)   This will give you a file fedora-23-aarch64, and simply rename this to fedora-23-aarch64.img.

Fedora 23 Image

Fedora 23 Image

As the Fedora aarch64 images are (at present..) intended for servers, the image includes a FAT EFI partition, followed by an EXT4 boot partition, followed by a SWAP partition, followed by the the actual rootfs partition, which is in XFS format…   These images are designed for use with QEMU etc., after all..     Most of my ARM devices use U-Boot with a FAT boot partition, rather than EFI, and it is relatively easy to create your own EXT4 partition on an SDcard, and then just copy the contents of the XFS rootfs across..

As you can see, the image partitions can be easily mounted locally, using the Gnome Disks utility..    The menu for this function is somewhat hidden, but is accessed by clicking on the little radio-button in the top left..

Robert Gadsdon.  April 25, 2016.

ARM64 – Pi3 Success – Almost..

After more ‘investigation’, I managed to find a working U-Boot for a 64-bit boot of the Raspberry Pi 3, by copying it from the boot directory of this: found towards the end of the latest 64-bit thread on the Pi Forum: .  Thanks to xyinao for putting it all together..

I copied the kernel Image etc into a Fedora 23 aarch64 SDcard, and it booted OK, but I noticed one odd thing…   There were only 3 CPU cores instead of 4..    I tested by booting the original Debian system, with the same kernel image, and there were 4…

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.036066] Detected VIPT I-cache on CPU1
[ 0.036112] CPU1: Booted secondary processor [410fd034]
[ 0.048091] Detected VIPT I-cache on CPU2
[ 0.048120] CPU2: Booted secondary processor [410fd034]
[ 0.060128] Detected VIPT I-cache on CPU3
[ 0.060158] CPU3: Booted secondary processor [410fd034]
[ 0.060218] Brought up 4 CPUs
[ 0.060349] SMP: Total of 4 processors activated.
[ 0.060375] CPU: All CPU(s) started at EL2

I wanted (as usual) to compile my own kernel, and found that the 4.5.0-based one at booted, but then hung..    I tried another (4.6-rc3-based) version at, and this one did boot successfully:

Fedora 23 (Twenty Three)
Kernel 4.6.0-rc3-next-20160413 on an aarch64 (ttyS0)
# uname -a
Linux rgpi3 4.6.0-rc3-next-20160413 #1 SMP Mon Apr 25 21:14:33 EDT 2016 aarch64 aarch64 aarch64 GNU/Linux

But…  I still only had three CPU cores:

# dmesg |grep CPU
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Boot CPU: AArch64 Processor [410fd034]
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: enabling workaround for ARM erratum 845719
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.102974] Detected VIPT I-cache on CPU1
[ 0.103023] CPU1: Booted secondary processor [410fd034]
[ 0.103417] Detected VIPT I-cache on CPU2
[ 0.103449] CPU2: Booted secondary processor [410fd034]
[ 1.107755] CPU3: failed to come online
[ 1.107766] CPU3: failed in unknown state : 0x0
[ 1.107785] Brought up 3 CPUs
[ 1.107801] CPU: All CPU(s) started at EL2

So… Nearly there, but more investigation needed..

Robert Gadsdon.   April 25, 2016.

Kernel – 4.6-rc5 – OK with (Patched) VMware, and (Patched) NVIDIA..

Kernel 4.6-rc5 is out, and brief details of changes from -rc4 are here:

Kernel 4.6 seems to have a habit of continuing later-rc breakages with VMware and NVIDIA, compared to previous kernel releases..

The VMware 12 fix for 4.6-rc4 (see ) still works OK with 4.6-rc5, but even the latest NVIDIA driver – 364.19 breaks with Kernel 4.6-rc4, and -rc5:

/home/rgadsdon/NVIDIA-Linux-x86_64-364.19/kernel/nvidia-drm/nvidia-drm-drv.c:67:18: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]

Fortunately there is already a patch, thanks to towo on the DevTalk forum:

I have applied this to 364.19 on Kernel 4.6-rc5, and everything compiles OK, now..

Robert Gadsdon.   April 24, 2016.

VMware – Later 4.6-rc breaks vmmon and vmnet..

Thanks to Justin Palermo, there is a patch for VMware 12 vmmon and vmnet problems he identified with the later Kernel 4.6-rcs.       See comments on my earlier 4.6-rc1 article for details:

I have applied the patch to VMware 12.1.0, on Kernel 4.6-rc4, and VMware now compiles and runs OK..

Robert Gadsdon.   April 22, 2016.

ARM – Rock2 – Kernel 4.6-rc4 – MMC Swaparound – Bug or Feature?

I had been running Kernel 4.2-rc2 on the Radxa Rock2 without any issues, and decided to update to recently-released Kernel 4.6-rc4..

Brief details of changes from -rc3 are here:

The boot failed, and I then compiled/installed 4.6-rc3 to see if that would have been OK, and it was..

I then noticed something odd in the failed boot process… It appeared that the MMC device references had swapped around in -rc4:

RC3 – and earlier (boot OK):

mmc0: new high speed SDXC card at address e624
mmcblk1: mmc0:e624 SL64G 59.5 GiB
 mmcblk1: p1

RC4 (boot failed):

mmc0: new high speed SDXC card at address e624
mmcblk0: mmc0:e624 SL64G 59.5 GiB
 mmcblk0: p1

So… a simple change to the u-boot kernel boot command – changing root=/dev/mmcblk1p1 to root=/dev/mmcblk0p1 – fixed the problem, and 4.6-rc4 booted OK..

Fedora 23 (Twenty Three)
Kernel 4.6.0-rc4 on an armv7l (ttyS2)
]# uname -a
Linux rgrock2 4.6.0-rc4 #1 SMP Wed Apr 20 18:44:57 EDT 2016 armv7l armv7l armv7l GNU/Linux

All that was needed then, was to change /etc/fstab accordingly.. (Yes – I still use the ‘traditional’ format!)

Initial investigation suggested that this might be the kernel patch responsible:

On the Rock2, this means that the on-board eMMC is now /dev/mmcblk1, and the SDcard is /dev/mmcblk0…   It will be interesting to see if this change affects any of my other ARM devices…..

Robert Gadsdon. April 20, 2016.

x86_64 – UP Board – Intel 64-bit, Size of a Pi..

Being the pioneer/masochist type (aka ‘early-adopter’..), I was intrigued by the new Intel Atom x5-Z8350-powered UP Board, and now have one on (pre)order..

Basic info, with too much graphics..

Not much info on their forum, yet, but it does have UEFI, so (speculation!) should boot with good old GRUB..  One thing it does not have is an SDcard connector, so will have to use a USB stick instead..

More info, when it arrives..

Robert Gadsdon.   April 18, 2016.

ARM64 – Pi3 64-Bit Tribulations.. Too Soon for Stability..

I had ordered a Raspberry Pi 3 back in March in the hope that it would be a useful exercise in 64-bit on a different chipset..    I was (somewhat) disappointed to find that there was no initial 64-bit support, and indeed that I had been a bit of a pioneer in even running armv7 code on my Pi 2!

After checking the GIT repositories in recent weeks for 64-bit U-Boot and Kernel, I started some tests..    The first painful discovery was the ‘hijacking’ of the UART/Console port on the device, for use by Bluetooth hardware…    This had echoes of the Geekbox SDcard/UART scenario mentioned in a previous article, but at least this time there seemed to be a workaround – of sorts, except that on my Pi3 (with a temporary 32-bit setup) I only saw the kernel boot output, and not the earlier U-Boot commands..

Some more info (and much ‘speculation’..) is on the Pi Forum:  There are some ‘instructions’ near the end of the thread..

I had tried to follow various instructions to get U-Boot working as a start, but ran up against the inevitable ‘moving target’ problem with GIT repositories..     The version that was alleged to work had been superseded, and in some cases the specified checkout version was no longer in existence..

There are (at least) two GIT repositories with U-Boot: and    I have – so far – not had any luck getting the first one to work, and the second version did show up, but aborted almost immediately:

U-Boot 2016.03-rc3-g96a6c2f (Apr 14 2016 - 23:45:59 -0700)

DRAM: 944 MiB
"Synchronous Abort" handler, esr 0x02000000
ELR: 3af4110c
LR: 3af4237c
x0 : 0000000000c51838 x1 : 000000000000000c
x2 : 000000000004f760 x3 : 000000000004f760
x4 : 000000003af636c4 x5 : 0000000000000160
x6 : 0000000000010000 x7 : 000000000000000a
x8 : 0000000007fff7b0 x9 : 000000003af41000
x10: 0000000000000000 x11: 0000000000000001
x12: 00000000ffffffff x13: 00000000ffffffff
x14: c0cb10620de021b8 x15: a98c11034c806420
x16: cd75c246083527b0 x17: 0000a00000000000
x18: 000000003ab3ce08 x19: 000000003ab3cce0
x20: 0481000000020000 x21: f37e600000000000
x22: 000000000000000d x23: 000000000002000d
x24: 001000006c5225e8 x25: 000000003e6a3d9a
x26: 21380000fcf19ef4 x27: 00000000a5ff98a5
x28: 0080000037b7f368 x29: 0000000000000084
Resetting CPU ...
resetting ...

<< repeats.... >>

I had no problem getting U-Boot to work on the Pi2, but this is a bit more complex…    There is another dimension to the moving targets, as it appears the Pi firmware has recently been updated, and when I loaded the latest version from the Pi GIT repository, even the second U-Boot stopped working, with nothing showing on the screen at all..

So…  My plan now is to leave everything until the dust has settled, and there is more stability in firmware/u-boot/kernel/ versions..      This was always just an academic exercise, in any case, as it has been pointed out by many that the Pi3 has too little memory available to take advantage of 64-bit processing, and in many circumstances would actually be slower than in 32-bit mode..

Robert Gadsdon.   April 15, 2016.

ARM64 – Geekbox – 8-Cores and a UART Gotcha..

I recently acquired on of the rather quirky Geekbox ARM64 devices, together with the oddly-named ‘Landingstrip’ expansion board..

The similarity in overall design to the ARMv7 Radxa Rock2 will be seen from the photo:

Geekbox ARM64

Geekbox ARM64

If you are ordering one, it is worth getting the USB/UART connector as well, as the 3-pin micro flat-pin connection is somewhat non-standard..

As part of my plans to get it running a ‘real’ kernel, with U-boot etc, I had intended to mount an SDcard with the root filesystem etc.. similar to the Rock2..    I found that when the SDcard was inserted, the UART console output became garbage..    Further research (and confirmation with the makers) revealed that the SDcard connection ‘shares’ the UART with the console/TTY (!)   This could be called a ‘design compromise’, but it certainly makes life a bit difficult for a developer..

I found out that there are more UART connections, via the multi-connector on the expansion board, but some of these were ‘shared’ with other peripherals (such as Bluetooth) and the two ‘available’ ones produced a stream of garbage characters when connected..    IMHO the UART/USB TTY connection is essential, so I had to re-think my approach…    Fortunately, the ‘Landingship’ board includes a SATA+power connector, suitable for a SSD, and so I connected a relatively inexpensive 120GB one, and now have Fedora 23 (aarch64) as the rootfs on that.    You could probably also use a USB stick, but I have not tried this..  The SATA connection is via a USB bus in any case.:

]# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge
Bus 001 Device 002: ID 1a40:0801 Terminus Technology Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The Linux environment provided with the device is based on a heavily-hacked version of ancient Kernel 3.10, which is loaded onto the on-board eMMC – with stripped-down u-boot, initrd, etc. – as a binary ‘blob’..    The kernel command line is loaded as part of a parameter file – similar to the original setup on the Radxa Rock2 – and I modified this to point to the F23 rootfs on the SSD (/dev/sda1).

There is active kernel development going on for the device (Rockchip RK3368 SOC), but (so far) no sign of any work on a ‘real’ U-boot..    The old/hacked kernel does boot OK with Fedora 23, but I keep getting Systemd errors, and tombstones, although the device does not actually crash (so far!)

Fedora 23 (Twenty Three)
Kernel 3.10.0 on an aarch64 (ttyS2)
# uname -a
Linux rgbox 3.10.0 #130 SMP PREEMPT Mon Dec 21 08:25:25 CST 2015 aarch64 aarch64 aarch64 GNU/Linux

More info to follow, when I have it!

Robert Gadsdon.   April 8, 2016.