ARM – Kernel 4.0-rc1 – Fix for CuBox-i4 Pro Networking..

The CuBox-i4 Pro booted Kernel 4.0-rc1 OK, but – although eth0 was present – there was no network connection possible..

I found a similar problem described on the Linux Arm Kernel mailing list:  http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325249.html

According to the info there, I changed linux/arch/arm/mach-imx/mach-imx6q.c as follows:

Around line 214, change

clksel = ptp_clk == enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP :
                                    IMX6Q_GPR1_ENET_CLK_SEL_PAD;

to

clksel = ptp_clk != enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP :
                                    IMX6Q_GPR1_ENET_CLK_SEL_PAD;

Recompile / install, and networking now works correctly..

......................
fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
......................
Fedora release 22 (Twenty Two)
Kernel 4.0.0-rc1 on an armv7l (ttymxc0)
.......................
[root@rgcubox ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default dsl_router 0.0.0.0 UG 100 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
[root@rgcubox ~]# ping rglinux-i7
PING rglinux-i7 (192.168.0.2) 56(84) bytes of data.
64 bytes from rglinux-i7 (192.168.0.2): icmp_seq=1 ttl=64 time=0.341 ms
64 bytes from rglinux-i7 (192.168.0.2): icmp_seq=2 ttl=64 time=0.173 ms
64 bytes from rglinux-i7 (192.168.0.2): icmp_seq=3 ttl=64 time=0.171 ms
--- rglinux-i7 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.171/0.228/0.341/0.080 ms

So – I now have Kernel 4.0-rc1 running successfully on the CuBox-i4 Pro..

Robert Gadsdon.  February 24, 2015.

ARM – Kernel 4.0-rc1 – Not Much Joy….Yet..

Tried Kernel 4.0-rc1 on the CuBox-i4 Pro (from kernel.org) and the Odroid U3 (from https://github.com/tobiasjakobi/linux-odroid/tree/odroid-4.0.y), and the results are a bit of a mixed bag..

The CuBox boots OK, but – although eth0 appears to be present – networking doesn’t work..

Fedora release 22 (Twenty Two)
Kernel 4.0.0-rc1 on an armv7l (ttymxc0)
................
[root@rgcubox ~]# uname -a
Linux rgcubox 4.0.0-rc1 #1 SMP Mon Feb 23 01:02:22 EST 2015 armv7l armv7l armv7l GNU/Linux
......................
$ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
 ether d0:63:b4:00:31:3d txqueuelen 1000 (Ethernet)
 RX packets 0 bytes 0 (0.0 B)
 RX errors 0 dropped 0 overruns 0 frame 0
 TX packets 0 bytes 0 (0.0 B)
 TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
..........................
# systemctl status network.service -l
● network.service - LSB: Bring up/down networking
 Loaded: loaded (/etc/rc.d/init.d/network)
 Active: failed (Result: exit-code) since Mon 2015-02-23 13:53:14 EST; 29s ago
 Docs: man:systemd-sysv-generator(8)
 Process: 384 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
Feb 23 13:53:12 rgcubox network[384]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Feb 23 13:53:13 rgcubox network[384]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Feb 23 13:53:13 rgcubox network[384]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
Feb 23 13:53:13 rgcubox network[384]: [ OK ]
Feb 23 13:53:14 rgcubox network[384]: Bringing up interface eth0: Error: Connection activation failed: Connection 'System eth0' is not available on the device eth0 at this time.
Feb 23 13:53:14 rgcubox network[384]: [FAILED]
. etc.................   (and yes, all the necessary ifcfg files are in the right place!)

The Odroid U3 fails to boot:

........
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected
INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 1, t=12002 jiffies, g=-249, c=-250, q=33)
Task dump for CPU 0:
swapper/0 R running 0 1 0 0x00000002
Backtrace:
[<ee081c8c>] (0xee081c8c) from [<ee081cbc>] (0xee081cbc)
Backtrace aborted due to bad frame pointer <ee0142c0>

So.. More testing is needed!   The CuBox might possibly be affected by compiling the kernel with the Fedora 22 5.0 version of gcc, but this is unverified at the moment..   I may (re)compile the (working) 3.19.0 kernel with gcc 5.0, to test this..

Robert Gadsdon.    February 23, 2015.

 

NVIDIA – Driver Fix, for Kernel 4.0. and Earlier..

I have hacked together a kernel-version-friendly fix for the latest NVIDIA driver (346.35) which works with Kernel 4.0-rc1 (and later) and also for previous kernel versions..   Thanks are due to juston_li for producing the actual code changes needed..  https://devtalk.nvidia.com/default/topic/813458/linux/linux-4-0-rc1-346-35-build-error-_cr4-functions-fix/

Unpack the NVIDIA driver:

./NVIDIA-Linux-x86_64-346.35.run -x

Edit NVIDIA-Linux-x86_64-346.35/kernel/nv-pat.c

Around line 34, change

{
 unsigned long cr0 = read_cr0();
 write_cr0(((cr0 & (0xdfffffff)) | 0x40000000));
 wbinvd();
 *cr4 = read_cr4();
 if (*cr4 & 0x80) write_cr4(*cr4 & ~0x80);
 __flush_tlb();
}

to

{
 unsigned long cr0 = read_cr0();
 write_cr0(((cr0 & (0xdfffffff)) | 0x40000000));
 wbinvd();
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 0, 0)
 *cr4 = read_cr4();
 if (*cr4 & 0x80) write_cr4(*cr4 & ~0x80);
 __flush_tlb();
#else
 *cr4 = __read_cr4();
 if (*cr4 & 0x80) __write_cr4(*cr4 & ~0x80);
 __flush_tlb();
#endif
}

..and around line 46, change

  wbinvd();
  __flush_tlb();
  write_cr0((cr0 & 0x9fffffff));
  if (cr4 & 0x80) write_cr4(cr4);
 }

to

  wbinvd();
  __flush_tlb();
  write_cr0((cr0 & 0x9fffffff));
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 0, 0)
  if (cr4 & 0x80) write_cr4(cr4);
 #else
  if (cr4 & 0x80) __write_cr4(cr4);
 #endif
 }

Then recompile, etc…

I have tested this with both Kernel 4.0-rc1 and 3.19.0, and the compile now completes successfully on both versions..

Robert Gadsdon.   February 23, 2015.

Kernel – Welcome to Linux 4.0? VMware (Patched) OK, NVIDIA Fix Available..

Just tested Kernel 4.0-rc1 – announced here:  http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html

As you will see – not much actual detail on what has changed, and I have already run into a couple of ‘issues’…

The Radeon drm driver on my laptop refuses to load, and the boot hangs immediately with

drm r600_ring_test [radeon] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xFFFFFFFF)
radeon 0000:01:00.0: disabling GPU acceleration

The workaround is to disable the drm driver, and just use the framebuffer one, for the time being..

VMware 11.1.0 – with the vmnet patches – loads and runs OK..

NVIDIA driver 346.35 fails to compile:

/home/rgadsdon/NVIDIA-Linux-x86_64-346.35/kernel/nv-pat.c: In function ‘nv_disable_caches’:
/home/rgadsdon/NVIDIA-Linux-x86_64-346.35/kernel/nv-pat.c:38:5: error: implicit declaration of function ‘read_cr4’ [-Werror=implicit-function-declaration]
 *cr4 = read_cr4();
 ^
/home/rgadsdon/NVIDIA-Linux-x86_64-346.35/kernel/nv-pat.c:39:5: error: implicit declaration of function ‘write_cr4’ [-Werror=implicit-function-declaration]
 if (*cr4 & 0x80) write_cr4(*cr4 & ~0x80);
 ^
cc1: some warnings being treated as errors

Thanks to juston_li at the NVIDIA DevZone forums, there is a simple fix, but the example is – as is mentioned – only for 4.0 and later, and needs to have kernel version tests added, to leave the code as-is for pre-4.0 kernels..

https://devtalk.nvidia.com/default/topic/813458/linux/linux-4-0-rc1-346-35-build-error-_cr4-functions-fix/

More test are needed, but at least it booted OK, after the above ‘workarounds’..

$ uname -a
Linux rg6830l 4.0.0-rc1 #1 SMP Sun Feb 22 23:51:39 PST 2015 x86_64 x86_64 x86_64 GNU/Linux

Robert Gadsdon.   February 22, 2015.

ARM – Raspberry Pi ‘Classic’ – Device Tree Kernel Compile..

After my tests compiling the new armv7 Pi 2 Kernel – with ‘device tree’ – I decided to try the same with the ‘classic’ armv6 Pi (B+)..

You will need the latest version of the Pi /boot files, including the latest config.txt with the necessary parameters for device tree boot, sound config, etc..

For cross-compilation, I created a pi directory on my x66 system, and used git to download a Pi 3.19.0 kernel tree there:

git clone -b rpi-3.19.y --single-branch https://github.com/raspberrypi/linux

Then created a ~/boot directory to contain the kernel, dtb and System.map files..

Then, in the linux directory:

export ARCH=arm
export CROSS_COMPILE=armv7hl-mandriva-linux-gnueabi-  (or whatever cross-compiler you use..  don't forget the "-" at the end!)
export INSTALL_PATH=../    (install the files locally, within the pi directory)
export INSTALL_MOD_PATH=../ (install the ~/lib/modules files locally, within the pi directory)

Then:

make bcmrpi_defconfig (if necessary..)
make xconfig 
make
make modules_install
make firmware_install
cp System.map ../boot
cp arch/arm/boot/dts/bcm2708-rpi-b-plus.dtb ../boot
cp arch/arm/boot/Image ../boot/kernel.img   (Pi armv6 kernel is still called kernel.img)

This will create the kernel, modules, and boot/dtb files all within the local directory created at the start..

Then shut down the Pi, mount its SDcard, and copy files across to its /boot and /lib/modules and /lib/firmware directories..

Re-insert the SDcard, and connect power:

Pidora release 2014 (Raspberry Pi Fedora Remix)
Kernel 3.19.0 on an armv6l (ttyAMA0)
.................
# uname -a
Linux rgpi 3.19.0 #1 PREEMPT Sat Feb 21 15:24:00 PST 2015 armv6l armv6l armv6l GNU/Linux

Robert Gadsdon.   February 21, 2014.

 

ARM – Raspberry Pi 2 – Kernel Compile..

Finally got the Raspberry Pi 2, and installed Fedora 21 (armv7hl) with no problems..    Temporarily used object code 3.18.7-v7+ from the repository, and then tested kernel compile options..

The system seems (so far..) to be relatively sluggish compared to my other quad-core armv7 systems..   Compiling on the Pi 2 itself seemed relatively slow, but at least it was a realistic option..!

I got the latest (3.19.0) kernel from https://github.com/raspberrypi/linux/tree/rpi-3.19.y

Compiling the kernel + device tree was somewhat different from the Classic armv6 Pi…   As usual, there are other ways of doing this, but this works, for me..

First time, run # make bcm2709_defconfig to get correct Pi 2 config..
or
Create config from (running) /proc/config.gz

make xconfig   (if necessary..)
make
make modules_install
make firmware_install
cp System.map /boot
cp arch/arm/boot/dts/bcm2709-rpi-2-b.dtb /boot
rm -f /boot/kernel7.img.old
mv /boot/kernel7.img /boot/kernel7.img.old  (save the old/good kernel, just in case..)
cp arch/arm/boot/Image /boot/kernel7.img

One thing to remember is that kernel7.img is just a copy of arch/arm/boot/Image, and there is no longer a requirement for tools/imagetool-uncompressed.py

If you want to call the kernel7.img file something else, just put a kernel=xxxxxx parameter in /boot/config.txt

If all goes well, you should see a clean boot…

$ uname -a
Linux rgpi2 3.19.0-v7 #2 SMP PREEMPT Wed Feb 18 19:31:57 PST 2015 armv7l armv7l armv7l GNU/Linux

I did get the kernel compile to crash gcc at one point, but when I re-ran it, all was well..    I did check the cpu temperature while compiling, and it was around 41C..

Robert Gadsdon.  February 18, 2015.

VMware – 11.1 Released – Still Broken with Kernel 3.19..

Just updated the test system to VMware Workstation 11.1, and – unfortunately – this is still incompatible with Kernel 3.19..

The only good news is..  The vmnet patch for 11.0 still applies, and fixes the problem..  http://rglinuxtech.com/?p=1281

The release notes (for what it’s worth!) are here:  https://www.vmware.com/support/ws/doc/workstation-111-release-notes.html

As you can see – quite a lot of ‘known problems‘…

Robert Gadsdon.    February 17, 2014.

ARM – Odroid U3 Fan Control – Success..

Updated the Odroid U3 to the latest version of odroid-3.19.y (# git clone -b odroid-3.19.y –single-branch https://github.com/tobiasjakobi/linux-odroid ).

After checking that all the pwm-fan and temperature options were selected in the kernel config, I set ‘Default Thermal governor‘ to ‘step-wise‘.

After compiling/installing, I tried some more tests:

Using ‘stress’ to raise the temperature:

# stress --cpu 4 --timeout 60
stress: info: [2842] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

– after around 30 seconds, the temperature is above the 70 degree mark, and the fan starts..

When stress finishes, temperature drops to around 65, and the fan stops..

[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
69000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
70000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
71000
<<< fan starts >>>
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
71000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
71000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
71000
.....................
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
70000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
70000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
70000
<< stress stops >>>
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
71000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
70000
....................
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
65000
<< fan stops >>
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
63000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
60000
[root@rgodroid rgadsdon]# cat /sys/devices/virtual/thermal/thermal_zone0/temp
60000

So now the fan is ‘automatic’, without the need for any external programs..

Thanks to tobiasjakobi for his help with this, and porting the latest (v6) patches to odroid-3.19.y.

Robert Gadsdon.   February 15, 2015.

RPM – Fixing ‘Ancient’ Source Rebuilds..

I had occasion to install an ancient GTK+ app, recently, and had to use # rpmbuild –rebuild xxxxx.src.rpm to (re)create some old RPMs from source..

I got the following error:

/home/rgadsdon/rpmbuild/BUILD/php_gtk-1.0.2/main/php_gtk_object.c: In function 'php_gtk_args_from_hash':
/home/rgadsdon/rpmbuild/BUILD/php_gtk-1.0.2/main/php_gtk_object.c:410:4: error: format not a string literal and no format arguments [-Werror=format-security]
 php_error(E_WARNING, buf);
 ^

So, I needed to remove the -Werror=format-security parameter from the compile…

To do this, on a Fedora system, edit /usr/lib/rpm/redhat/macros and change %__global_cflags…….. to remove -Werror=format-security.

Then, the compile completes successfully..

You probably want to change /usr/lib/rpm/redhat/macros back to its original state, afterwards..

Robert Gadsdon.   February 12, 2015.