VMware – Fix for Kernel 4.2..?

Thanks to craigacgomez on the VMware Forum, there is a hack to fix VMware (vmnet) with Kernel 4.2..  https://communities.vmware.com/thread/516196

I made some more changes, to make it backward-compatible, and it seems to work OK with Kernels 4.1.3 and 4.2-rc4..

I should emphasize that I am an amateur at such things, but if you want to try this, then this is what I did, after expanding vmnet.tar:

In vmnet-only/vmnetInt.h..

Around line 79, change:

# define compat_sk_alloc(_bri, _pri) sk_alloc(&init_net, \
                        PF_NETLINK, _pri, &vmnet_proto,)
# define compat_sk_alloc(_bri, _pri) sk_alloc(PF_NETLINK, _pri, &vmnet_proto, 1)


# define compat_sk_alloc(_bri, _pri) sk_alloc(&init_net, \
                        PF_NETLINK, _pri, &vmnet_proto, 1)
# define compat_sk_alloc(_bri, _pri) sk_alloc(&init_net, \
                        PF_NETLINK, _pri, &vmnet_proto)
# define compat_sk_alloc(_bri, _pri) sk_alloc(PF_NETLINK, _pri, &vmnet_proto, 1)

I have applied this change, and VMware compiles and runs OK on Kernel 4.1.3, and 4.2-rc4..

YMMV…  Usual disclaimer applies!

Robert Gadsdon.    August 1, 2015.

ARM64 – HiKey – Change to UEFI Boot..

After some more testing, including trying (unsuccessfully) the HiKey version of Kernel 4.1-rc4 # git clone -b hikey-mainline-rebase –single-branch https://github.com/96boards/linux/   I was frustrated by the complete lack of kernel boot info on screen, after the proprietary bootloader had finished.. More research found that this bootloader was described as somewhat deficient in the ‘fit for purpose’ department, and I really ought to update to a more effective one…

There is a pre-release version of U-Boot available, but UEFI/grub is also now an option, which made more sense..     The only drawback to the current version of UEFI is that it can only boot from Emmc, not an SD Card, but as long as the kernel image (Image) and dtb (hi6220-hikey.dtb) and initrd are resident on the Emmc boot partition, then the rootfs can still be on the SD Card..     I also created a SWAP file on the Emmc root partition..

[root@rghikey ~]# cat /etc/fstab
/dev/mmcblk1p2  /           ext4  defaults 1 1
/dev/mmcblk1p1  /boot       vfat  defaults 1 2
/dev/mmcblk0p6  /boot-emmc  vfat  defaults 1 2
/dev/mmcblk0p9  /root-emmc  ext4  defaults 1 2
/root-emmc/SWAP none        swap  defaults 0 0

So.. I have the root filesystem on the SD Card, and mount the Emmc boot and root partitions as /boot-emmc and /root-emmc respectively, and then copy the Image and .dtb files to the /boot-emmc partition after compilation..     This is far more useful, as by editing the grub configuration file in the Emmc boot directory (/boot-emmc/grub/grub.cfg) I can arrange for multiple Kernel versions to be available for booting, to fall-back to a known/good version if the boot fails..

$ cat /boot-emmc/grub/grub.cfg 
set default="0" 
set timeout=10 
menuentry 'Fedora Linux' { 
    linux /Image console=ttyAMA0,115200n8 earlycon=pl011,0xf8015000 root=/dev/mmcblk1p2 rw roo
twait initrd=initrd.img efi=noruntime 
    initrd /initrd.img 
    devicetree /hi6220-hikey.dtb 
menuentry 'Fedora Linux OLD' { 
    linux /Image.old console=ttyAMA0,115200n8 earlycon=pl011,0xf8015000 root=/dev/mmcblk1p2 rw
 rootwait initrd=initrd.img efi=noruntime 
    initrd /initrd.img 
    devicetree /hi6220-hikey.dtb.old 
menuentry 'Fedora Linux 4.1-rc4' { 
    linux /Image-41rc4 console=ttyAMA0,115200n8 earlycon=pl011,0xf8015000 root=/dev/mmcblk1p2 
rw rootwait initrd=initrd.img efi=noruntime 
    initrd /initrd.img 
    devicetree /hi6220-hikey.dtb-41rc4 
Apart from the multi-version boot convenience, the resulting console output gives far more early-kernel-boot info than the old bootloader, enabling proper diagnosis of boot failures, rather than an empty screen.
Caveats..    You may need to try different versions of the UEFI binaries, as I found that the July 19 version failed, but an earlier version worked OK..    You will also need to connect  a proper uart/usb console to the circuit board, which may involve some careful soldering.. (see previous article http://rglinuxtech.com/?p=1509)
More to come – including the USB port catch-22, and Bluetooth woes..!
Robert Gadsdon.    July 22, 2015.

ARM64 – DragonBoard to 4.2-rc1 – And Back Again..

Updated the DragonBoard 410c to patched Kernel 4.2-rc1 from https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/refs/heads/integration-linux-qcomlt , and the system booted OK:

Fedora release 22 (Twenty Two)
Kernel 4.2.0-rc1+ on an aarch64 (ttyMSM0)
# uname -a
Linux rg410c 4.2.0-rc1+ #2 SMP PREEMPT Thu Jul 16 15:14:27 PDT 2015 aarch64 aarch64 aarch64 GNU/Linux

– But, on further testing, the SD Card (mmc1) had not been detected/connected:

# dmesg |grep mmc
[ 1.054080] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using ADMA 64-bit
[ 1.114173] mmc1: SDHCI controller on 7864900.sdhci [7864900.sdhci] using ADMA 64-bit
[ 1.124414] mmc0: MAN_BKOPS_EN bit is not set
[ 1.148855] mmc0: new high speed MMC card at address 0001
[ 1.151959] mmcblk0: mmc0:0001 DS2008 7.28 GiB
[ 1.155796] mmcblk0boot0: mmc0:0001 DS2008 partition 1 4.00 MiB
[ 1.163796] mmcblk0boot1: mmc0:0001 DS2008 partition 2 4.00 MiB
[ 1.166340] mmcblk0rpmb: mmc0:0001 DS2008 partition 3 4.00 MiB
[ 1.192548] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
[ 1.332180] mmc1: Reset 0x1 never completed.
[ 1.515375] mmc1: Reset 0x1 never completed.
[ 1.697062] mmc1: Reset 0x1 never completed.
[ 1.888422] mmc1: Reset 0x1 never completed.

So.. Reverted to the qcom-patched 4.0 kernel, again..

This was an issue with the 4.1 patched kernel, as well..    Hopefully this will get fixed soon, now that some patches are entering the official kernel.org tree..

Robert Gadsdon.   July 16, 2015.

ARM – Pi2 to U-Boot..

I decided to try U-Boot on the Raspberry Pi 2, and the process has been fairly well documented in several places..

I used the latest U-Boot, with ‘patch’ info from here, as I needed Device Tree support:  https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=108217.

Actual ‘installation’ is simple, as I just copied the u-boot binary to the boot directory on the SD Card, and edited config.txt to ‘boot’ U-Boot instead of the actual kernel, by changing kernel=kernel7.img to kernel=u-boot.bin.

On first boot, the uart/console output looked like this:

U-Boot 2015.07-rc3 (Jul 14 2015 - 13:49:19 -0700)

DRAM: 880 MiB
WARNING: Caches not enabled
RPI 2 Model B
MMC: bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In: serial
Out: lcd
Err: lcd
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0

After this, I added definitions to set up the necessary boot parameters, etc.:

setenv machid 0x00000c42
setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd'
setenv x_bootcmd_kernel fatload mmc 0:1 ${kernel_addr_r} zImage
setenv x_bootcmd_fdt fatload mmc 0:1 ${fdt_addr_r} bcm2709-rpi-2-b.dtb
setenv bootcmd '${x_bootcmd_kernel}; ${x_bootcmd_fdt}; bootz ${kernel_addr_r} - ${fdt_addr_r};'

saveenv (to save the parameter info to uboot.env on the SD Card)

Note that you do not need to explicitly state the kernel and device tree file load addresses, as – with the patch – these are already defined in the compiled U-Boot executable (as kernel_addr_r and fdt_addr_r respectively).
Of course, there are alternative ways of doing this, but this is a format I have used before with other devices..

I had been booting kernel7.img as an ‘uncompressed’ Image, but U-Boot expects zImage or uImage formats, so I changed my compile workflow on the Pi2 accordingly:

make -j5 zImage
make dtbs
make -j5 modules
make modules_install
make firmware_install
cp System.map /boot
cp arch/arm/boot/dts/bcm2709-rpi-2-b.dtb /boot
cp arch/arm/boot/zImage /boot

My next project will probably be to see if I can get U-Boot running on the ARM64 HiKey, but that might be a bit premature…

Robert Gadsdon.   July 15, 2015.

ARM64 – HiKey With Proper UART Connection..

One of the most annoying missing features of the HiKey ARM54 board is the lack of a proper UART connection, to enable the same degree of boot information as other SoC systems..     There is a 4-pin/hole connection point, but no actual connector…    So, I had to get out the (mini) soldering iron, and magnifying goggles, and use a not-so-steady hand..

I managed to solder on three pin-type connectors, cut from a strip of a dozen or so, and then use female push-on connectors to the 1.8v USB/UART tail..

HiKey UART Connection

HiKey UART Connection

After this, I got a proper boot / console display (on /dev/ttyAMA0):

debug EMMC boot: print init OK
debug EMMC boot: send RST_N .
debug EMMC boot: start eMMC boot......
load fastboot1!
#PMU LDO15_REG_ADJ:0x00000054, STATUS3_LDO9_16:0x00000048
#PMU LDO22_REG:ADJ:0x00000057, STATUS4_LDO17_22:0x00000026
[BDID]boardid: 777 <7.7.7>
#select_hw_config, 58, board_id:0x0000002b
#select_hw_config, 71, array index:0
baudRate=115200, g_baudRate=115200
get_efuse_value,efuse ATE_flag temp:0x02800000.
ATE PASS,ate flag value:0x00000001.
get_efuse_value,efuse acpu_freq change level:0xb6baeb00.
get_efuse_value,efuse afreq change level val:0x00000000.
get_efuse_value,efuse acpu_freq level:0xb6baeb00.
get_efuse_value,efuse acpu freq sys level:0x00000000.
###INFO###,soc_freq = hw_afreq, efuse_afreq:1200000,hw_afreq:1200000.
efuse ACPU 1.4G HPM:0.
efuse ACPU 1.2G HPM:0.
efuse ACPU 960M HPM:0.
fastboot: acpu_dvfs_init successful!
acpu_get_dvfs_volt,g_afreq_max_pro is :5▒▒acpu max freq:1200000.
acpu support freq num:5
volt:0x0000003a 0x0000003a 0x0000004a 0x0000005b 0x0000006b
acpu start prof:0x00000004
acpu magic:0x5a5ac5c5
#### success !!!!! set_acpu_freq: acpu support freq num is 5 and start is 4 .
get_ddr_type 1; (lpddr2: 0; lpddr3: 1)
ddr_init(): get_ddr_type: 1
 ddr freq: 800000
in lpddr3_init: mode: 0; freq_config: 800
...... etc.......

This is (IMHO) essential for proper development and testing, especially as this device (unlike the DragonBoard 410c) has a version of U-Boot available, and also supports UEFI..  https://github.com/96boards/documentation/wiki/HiKeyUEFI

So far, I have not been able to get a newer compiled Kernel to boot, but this UART console connection will help to get things working….

Robert Gadsdon.  July 11, 2015.

ARM64 – And Now… 8 Cores!

I had another ARM64 system on order for some time, and – unexpectedly – it shipped a few days ago..

It is an 8-core ‘Hikey’ board, based on the same 96Boards outline as the DragonBoard 410c..

Hikey 8 Core ARM64

Hikey 8 Core ARM64

So far, I have it booting – with the Linaro/Hikey 3.18 kernel – and have put Fedora 22 on it..

Fedora release 22 (Twenty two)
Kernel 3.18.0-linaro-hikey on an aarch64 (tty1)
# uname -a
Linux rghikey 3.18.0-linaro-hikey #1 SMP PREEMPT Wed Jul 1 17:32:09 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux

It is fascinating to see it boot, with eight ‘Tux’s in a row!

$ cat /proc/cpuinfo
Processor : AArch64 Processor rev 3 (aarch64)
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 
CPU implementer : 0x41
CPU architecture: AArch64
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 3
Hardware : HiKey Development Board

At least this board does not need the Android fastboot to update the kernel image, and kernel compilation can more easily be done on the system itself, rather than cross-compiling..    Next stage will be to see if I can get the 4.1-rc4 Linaro kernel to boot successfully..

Robert Gadsdon.   July 8, 2015


Kernel – 4.2-rc1 – and rc2 – and -rc3 – Breaks Nvidia and VMware..

Update:   Same results with 4.2-rc3..    (RG  July 19)

Update:   Kernel 4.2-rc2 fails with VMware (vmnet) and NVIDIA in the same ways..     (RG July 14)

Updated to kernel 4.2-rc1 on the test system:

# uname -a 
Linux rg6830l 4.2.0-rc1 #1 SMP Sun Jul 5 18:36:06 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
VMware 11.1.2 vmnet fails to compile:
/tmp/modconfig-aJnfZl/vmnet-only/bridge.c: In function ‘VNetBridgeUp’:
/tmp/modconfig-aJnfZl/vmnet-only/bridge.c:952:17: error: too few arguments to function ‘sk_alloc’
 bridge->sk = compat_sk_alloc(bridge, GFP_ATOMIC);
In file included from /tmp/modconfig-aJnfZl/vmnet-only/compat_sock.h:23:0,
 from /tmp/modconfig-aJnfZl/vmnet-only/bridge.c:35:
include/net/sock.h:1515:14: note: declared here
 struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
scripts/Makefile.build:258: recipe for target '/tmp/modconfig-aJnfZl/vmnet-only/bridge.o' failed
– And the latest NVIDIA drivers (352.21 and 346.82) also fail to load, with another ‘GPL-only’ issue:
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'flush_workqueue'
/usr/src/linux-4.2-rc1/scripts/Makefile.modpost:90: recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1
/usr/src/linux-4.2-rc1/Makefile:1383: recipe for target 'modules' failed
make[2]: *** [modules] Error 2
The NVIDIA issue has already been noted by one of the Kernel devs, and hopefully the necessary official changes to workqueue.c can be made soon..  https://forums.geforce.com/default/topic/849487/linux-v4-2-uses-gpl-only-symbol-flush_workqueue-/
Robert Gadsdon.    July 5, 2015

ARM64 – DragonBoard 410c to Kernel 4.1..

Managed to update the DragonBoard 410c to Linaro Kernel 4.1.0+, from here:

git clone https://git.linaro.org/landing-teams/working/qualcomm/kernel.git -b integration-linux-qcomlt

So far, I have made the kernel ‘monolithic’ with all necessary modules built-in (‘y” instead of ‘m’), as this was how the original Linaro/Qualcomm kernel was built..     As the 410c uses the android fastboot, it would seem that the kernel/boot image has to be a ‘blob’ – including an initrd and device tree file, as well as the kernel itself…    Instructions can be found at https://github.com/96boards/documentation/wiki/Dragonboard-410c-Boot-Image

The result was a kernel that booted OK, but was not particularly stable..

Fedora release 22 (Twenty Two)
Kernel 4.1.0 on an aarch64 (ttyMSM0)
# uname -a
Linux rg410c 4.1.0 #1 SMP PREEMPT Wed Jul 1 19:50:26 PDT 2015 aarch64 aarch64 aarch64 GNU/Linux

Trying to run # vncserver resulted in a crash, and required a reboot to continue…    I will need to check the kernel config to see if there is anything obvious missing, or mis-configured..

It is rather odd having a system that cannot update/load its own kernel, and hopefully – once more of these are produced – the U-Boot team will be able to provide a more conventional boot setup..

Robert Gadsdon.   July 1, 2015.

ARM – Fedora 22 on ARM64..

After quite a lot of messing about, I got Fedora 22 running on the ARM64 DragonBoard 410c:

Fedora release 22 (Twenty Two)
Kernel 4.0.0-linaro-lt-qcom on an aarch64 (ttyMSM0)
$ uname -a
Linux rg410c rg410c.almaden 4.0.0-linaro-lt-qcom #1 SMP PREEMPT Fri Jun 5 15:17:06 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux

Still running the ‘stock’ Linaro/Qualcom version of Kernel 4.0.0+, but I am carrying out more tests with compiling my own..

As the device relies on the Android-centric fastboot rather than U-Boot, I have a suspicion that the kernel will need to be entirely monolithic, but I need to do some more work on this..   I did get the device booted with Kernel 4.1-rc8 compiled from Linaro source, but some of the functionality was missing..

Fortunately, support for an AX88179 ethernet/usb adapter was included in the kernel, and so I was able to set up a LAN connection easily..

More details to follow…

Robert Gadsdon.   June 30, 2015.

ARM – ARM64 Developments…

Just took delivery of a Qualcomm Dragonboard 410c (https://developer.qualcomm.com/hardware/dragonboard-410c) :

Dragonboard 410c

Dragonboard 410c

The unit is based on a ‘standard’ (96Boards) design, with a few quirks..   The device uses fastboot rather than U-Boot, and in this respect is more like flashing a custom ROM on a cellphone!    It even has on-board volume up/down buttons..

There is no Ethernet built-in, so I will be attaching a USB/Ethernet dongle..   A UART connection is on the board, but it is 1.8v instead of the more common 3.3v.   There is a 1.8v USB/UART connector available from another supplier, and I have one on order, along with a 12v DC power supply….

Android is pre-installed, but I will – of course – be installing Linux..    There is a Ubuntu boot/install image available, and I will be replacing the root filesystem etc. with a Fedora 22 one, and then recompiling my own Kernel, as usual..    This process will be similar to the time I booted the Odroid U3 for the first time..

There are ‘official’ Fedora 22 aarch64 install images available, but these appear to be for EFI boot, for servers.    I did manage to find a raw disk image, including a root fs, at: https://dmarlin.fedorapeople.org/fedora-arm/aarch64/builder/

I will post more details when I have all the parts, and get the system up and running..

Robert Gadsdon.   June 25, 2015.