fidzu : Linux-to-go

Over the past year people have asked which options they need to enable when using a recent udev/systemd/udisks/powertop in angstrom so here's a list of the most important ones:

devtmpfs:

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

This is needed for modern udev versions. The kernel will handle all the device node creation and deletion. This removes the need for udev-cache.

cgroups:

CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_FREEZER=y

Cgroups are needed for systemd.

Fuse/cuse:

CONFIG_FUSE_FS=y
CONFIG_CUSE=y

Fuse is nice to have and various libraries uses it for user-mounts (e.g. GIO).

taskstats:

CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

This makes powertop give usefull info about the processes that drain your battery.

Autofs:

CONFIG_AUTOFS4_FS=y

And this is what does the heavy lifting for the system on-demand mount feature.

06 Feb 2012 8:17am GMT

After having skipped FOSDEM in 2011, I wanted to go this year, especially because of the Golden Delicious stand where we had the OpenPhoenux GTA04 on show. A lot of people came around and were excited that someone picked up where Openmoko had left in 2009. The GTA04 is the true successor of the FreeRunner and I strongly invite all of you to support this movement by buying one. You will not get a more open mobile phone anywhere else.

I know that Brussels is always a bit colder than Frankfurt, so I tend to carry appropriate clothing… what I didn't expect though was that it was frickin' -20 on saturday. I have never been freezing more in my life. Lets cross fingers that I won't come back home with a cold. Especially due to the crazy public transportation situation. The Deutsche Bahn managed to accumulate a one hour delay on my way to Brussels - that's ok, however they managed to crash the engine in Aachen on my way back. So badly that we had to switch to a regional train and switch again in Cologne. Man… *sigh*

On to some good news… another thing I didn't expect was kind of an Openmoko family reunion. It was amazing to find Jan Lübbe, Stefan Schmidt, Daniel Willmann, Harald Welte, and even Rasterman hanging around at FOSDEM. That was just great. I also happened to share my hotelroom with Boudewijn which was unexpected but again very cool.

So despite the freezing, it was a great FOSDEM for me and I'm looking forward to go again next year, perhaps bringing Sabine and Lara Marie as well.

05 Feb 2012 6:08pm GMT

From time to time I read posts where people wrote that their Efika MX Smartbook does not boot any more. The only thing which it does is white power led blinking about twice per second. Standard reply in such case is "send device back to Genesi".

Some time ago a friend of mine borrowed Efika MX Smartbook from me. During his experiments he managed to get netbook into such state. I have serial/jtag debug dongle so decided to take a look at it (and unbrick device). I managed to fix it but also somehow broke serial port so can not check why my automate way does not want to work.

What needs to be done to get Smartbook back to live? Few things:

• SD card
• small screwdriver
• U-Boot from EfikaMX updater image
• U-Boot script which will flash U-Boot into NOR
• Linux account with root permissions
• working SD-bootable U-Boot - this one still requires serial dongle, sorry for that. Will replace it with proper one when will get serial port working again.

Needed steps:

1. Repartition SD card. You can use any tool for it. All what has to be done is set up first partition at 1MB offset so we have space for U-Boot.
2. Format partition (if needed) as FAT.
3. Run "sudo dd if=u-boot.imx of=/dev/sdd bs=1k seek=1" (replace /dev/sdd with your SD card).
4. Put card into SD slot of Efika MX Smartbook.
5. Take out keyboard - you need to use small screwdriver to push holes near F1, F6, F10, End keys.
6. Change DIP switches - they are in a middle of motherboard. You need to reverse default setup.
7. Power on your Efika. There should be U-Boot output on screen. You may even get system loaded up at this step ;)
8. Take out SD card and copy 'boot.scr' to it.
9. Power off Efika, put SD card and boot.
10. Old U-Boot will be stored into NOR flash (output will be visible on screen).
11. Change DIP switches - they are in a middle of motherboard. You need to reverse them to default setup.
12. Put keyboard back.
13. Take out SD card.
14. Boot your Efika MX Smartbook - operating system should load.

Some information:

• old U-Boot got flashed because new one was not tested for NOR boot
• finding out information for this how to took me few hours
• this procedure can be done without Efika MX Smartbook serial/jtag dongle
• similar procedure can be used for Efika MX Smarttop but as I do not have such I can not offer help

Thanks goes to:

• Genesi for giving me free Smartbook and serial/jtag dongle
• Marek Vasut for his work on mainlining U-Boot support for Efika MX devices
• Matt Sealey for some hints on IRC

All rights reserved © Marcin Juszkiewicz
Flashing U-Boot on Efika MX Smartbook was originally posted on Marcin Juszkiewicz website

01 Feb 2012 1:19pm GMT

The Linux kernel has a fairly extensive tracing infrastructure that is quite useful for debugging. There are a number of things you can do with tracing, but the focus of this article will be the traditional printk type debugging we often end up doing to trace initialization issues with a driver. The following links provide additional information on the linux kernel tracing infrastructure:

• http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/trace
• Debugging the kernel using Ftrace - part 1: http://lwn.net/Articles/365835/
• Debugging the kernel using Ftrace - part 2: http://lwn.net/Articles/366796/
• Secrets of the Ftrace function tracer: http://lwn.net/Articles/370423/
• http://elinux.org/Kernel_Trace_Systems

In this example, I am working on a new audio driver. The typical experience with a new driver is that you install it and nothing happens because something is not registered correctly with the Linux driver model. So, the first thing I do is start with with the platform_device_add() function in my drivers init function. To observe the kernel activity around the kernel platform code, I can do the following:

cd /sys/kernel/debug/tracing/
echo 0 > tracing_on (keep trace from filling up until we set filter)
echo function_graph > current_tracer
echo platform* > set_ftrace_filter
echo 1 > tracing_on
cat trace_pipe (leave running in a different shell)
<insmod my driver>

After executing the above, we see the following. For this example, trace_pipe is preferred because the trace is then emptied and only new information is shown.

0) + 30.518 us   |  platform_device_alloc();
0)               |  platform_device_add() {
0)   0.000 us    |    platform_uevent();
0) + 30.518 us   |  platform_uevent();
0)   0.000 us    |  platform_uevent();
0) + 30.518 us   |    platform_match();
0) + 30.518 us   |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();

...

0) + 30.518 us   |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();
0) ! 3936.767 us |  }
0) + 30.518 us   |  platform_uevent();
0) + 30.518 us   |  platform_device_alloc();

From the above, I can conclude that the platform_match() is not succeeding, because I would expect some more activity. At this point I chose to add a printk:

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 7a24895..f9ce0c7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -662,6 +662,8 @@ static int platform_match(struct device *dev, struct device_driver *drv)
        struct platform_device *pdev = to_platform_device(dev);
        struct platform_driver *pdrv = to_platform_driver(drv);

+       trace_printk("pdev->name = %s, drv->name = %s", pdev->name, drv->name);
+
        /* Attempt an OF style match first */
        if (of_driver_match_device(dev, drv))
                return 1;

Now, if I re-run the trace, I see the following:

 0)               |      /* pdev->name = soc_audio, drv->name = davinci_emac */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc_audio, drv->name = snd-soc-dummy */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc_audio, drv->name = soc-audio */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc_audio, drv->name = omap-pcm-audio */
 0)   0.000 us    |    }
 0) ! 4241.943 us |  } /* platform_device_add */

From the above, it looks like we have a simple mismatch between "soc_audio" and "soc-audio." Fixing this problem, and re-installing the module, we now have:

 0)               |    platform_match() {
 0)               |      /* pdev->name = soc-audio, drv->name = snd-soc-dummy */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc-audio, drv->name = soc-audio */
 0)   0.000 us    |    }
 0) + 91.553 us   |    platform_drv_probe();
 0) ! 4241.943 us |  } /* platform_device_add */

Now we can see that the names match, and the probe function is now being called. At this point, we may want to turn on tracing of some additional functions to try to determine what is happening next.

echo "platform* snd* mydriver*" > set_ftrace_filter

And the result:

 0)               |      /* pdev->name = soc-audio, drv->name = snd-soc-dummy */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc-audio, drv->name = soc-audio */
 0) + 30.517 us   |    }
 0)               |    platform_drv_probe() {
 0)               |      snd_soc_register_card() {
 0) + 30.518 us   |        snd_soc_instantiate_cards();
 0) ! 17852.78 us |      }
 0) ! 17883.30 us |    }
 0) ! 22125.24 us |  } /* platform_device_add */

With the above additional information, we can continue to learn more about the flow through the kernel.

While all of the above could have been done with printk's, it would have been more time consuming. The kernel function tracing capabilities allow us to quickly get a high level view of the flow through the kernel without manually adding a bunch of printk statements. The kernel tracing features are completely contained in the kernel without requiring additional user space utilities which makes it very convenient to use in embedded systems. The low overhead is also important in resource constrained embedded systems.

31 Jan 2012 1:12pm GMT

The good news is that BlueCore indeed has Deep Sleep mode, it's not marketing hype. It can be verified by configuring PSKEY_CLOCK_REQUEST_ENABLE to drive PIO when chip uses/doesn't use external clock. The key here is not to keep PSTool run (which well, you need to tweak sleep settings).

The bad news is that an HC-04 module in Deep Sleep still consumes 2.5mA, which is far too high for anything called Deep Sleep. So, something on the module besides BlueCore still consumes too much power. However, when BlueCore is held in reset state, entire module consumes 0.

Without Deep Sleep, simple LED flash task consumes 3.5mA, so there's not that much gain from the Deep Sleep...

30 Jan 2012 12:26am GMT

BlueFlashCmd.exe and other tools, part of CSR BlueSuite toolset to program BlueCore Bluetooth chips, has support for logging SPI communication with a chip. To enable it:

The key parameter here is SPIDEBUG_FILE - logging is activated when it's specified, and thus logging is always done to a file. One way to have logging go to a console is to use SPIDEBUG_FILE=con: , but then it won't be possible to redirect it.

Besides SPIDEBUG=ON, there're other logging levels/features:

• SPIDEBUG
• SPIDEBUG_REPRODUCIBLE
• SPIDEBUG_WRITES
• SPIDEBUG_READS
• SPIDEBUG_WIRE

The keys may be also specified in the environment instead of -trans switch arguments.

Looking at the output produced, it turns out it spends a lot in calibrating SPI speed, a way to that down is to use SPISLOW=ON setting right away.

29 Jan 2012 3:25pm GMT

Due to the various building works last year, the 675 was laid up off the road. I had planned to wait until spring to get it MOT'd (safety checked) and get it back on the road. With the mild weather there is not time like the present though.

After riding the CRM/YZ for the past months, getting back on a true road bike was very very odd. The amount the bars moved for slow speed manouvering was scary, the brakes seemed weak (but aren't), the throttle rather responsive, the clutch immediate and the raw accelation, grin worthy.

I did manage to remember how to ride it, the battery worked, the engine management didn't light up like a christmas tree and it gained an MOT. Triumph did a beautiful piece of engineering with that bike and I remember why I own it. We need some better weather but its ready and waiting .

27 Jan 2012 6:03pm GMT

When doing embedded Linux development, most of us spend out time tethered to a target system with a serial cable, which is used for a serial console. Minicom is the defacto serial terminal software for Linux. However, Minicom is a little fussy in that you typically have to set it up for each port you want to use. This is no big deal, but is generally difficult for new users to understand, and yet another hurdle. And with 8-port USB->serial adapters, I have a lot of ports to set up.

Just recently, I discovered that screen can be used as a serial terminal program:

screen /dev/ttyUSB0 115200

A few notes on using:

• to exit screen: Ctrl-a k
• to write a hardcopy of the screen image: Ctrl-a h
• to get help: Ctrl-?

All the neat features of screen are two numerous to list here, but one more that I'll point out is the scrollback/copy feature (activated by Ctrl-a [ ). This allows you to scroll back and the navigation works much like VI - what could be nicer?

26 Jan 2012 7:24pm GMT

The beaglebone kernel was timing out on I²C bus 2 when no cape is attached. This was traced back to missing pullups on the 2 I²C lines. Looking at the source:

"uart1_ctsn.i2c2_sda",    OMAP_MUX_MODE3 | AM33XX_SLEWCTRL_SLOW \
 | AM33XX_PULL_ENBL | AM33XX_INPUT_EN

That seems to enable pullups, let's check on the device itself:

root@beaglebone:~# devmem2 0x44e10978
devmem2 0x44e10978
/dev/mem opened.
Memory mapped at address 0x40313000.
Read at address  0x44E10978 (0x40313978): 0x00000063

The magic decoder ring gives us the following:

No pullups enabled, but pulldowns! Let's change the kernel to make it try a bit harder to enable pullups:

"uart1_ctsn.i2c2_sda",    OMAP_MUX_MODE3 | AM33XX_SLEWCTRL_SLOW \
 | AM33XX_PIN_INPUT_PULLUP},

The timeouts seem to be gone, let's double check:

root@beaglebone:~# devmem2 0x44e10978
devmem2 0x44e10978
/dev/mem opened.
Memory mapped at address 0x40313000.
Read at address  0x44E10978 (0x40313978): 0x00000073

Success!

25 Jan 2012 12:08pm GMT

EGL is defined here and appears to be in OpenGL ES something what GLUT was (?) in OpenGL world. At least, EGL is what takes care of actually displaying on screen what was rendered by OpenGL ES.

Donut

EGLNativeWindowType is defined in opengl/include/EGL/eglplatform.h as struct egl_native_window_t* . egl_native_window_t is defined nearby in opengl/include/EGL/eglnatives.h . This is nice, clean, standalone structure (unlike horror in Eclair+). It starts with a "magic" (signature) 0x600913, followed by "version" which is sizeof of the structure (now I know why Microsoft gets a buck on each Android phone sold - they for sure patented this (stupid? lazy?) trick widely used in Win32 API). There're some function pointers (virtual method table) used by EGL to call into native windowing system (deep, close to vendor drivers) to support its workings. Out of these, there's essentially one related to rendering finalization: swapBuffers(). So yes, it seems that eglSwapBuffers() just calls out to this. The structure also directly contains "Base memory virtual address of the surface in the CPU side" and other easily graspable memory/graphics notions.

It's clear that in its young years, Android was fair and naive, not suitable at all for typical vendor OpenGL mumbo-jumbo. The "fix" came with the later versions.

Eclair and following

EGLNativeWindowType is defined (in include/EGL/eglplatform.h) to be struct ANativeWindow*. ANativeWindow was android_native_window_t in Eclair, but was renamed to ANativeWindow in Froyo (android_native_window_t is still available for compatibility). ANativeWindow is defined in platform/frameworks/base/include/ui/egl/android_natives.h:

• Eclair
• Froyo
• Gingerbread

ANativeWindow not just emulates VMT, but seems to want to do entire C++ in C-like manner in its metes and bounds. It uses subclassing from android_native_base_t, and that contains fields for magic ("_wnd" for ANativeWindow) and version-sizeof. Methods defined are also more involved. Among the most interesting are dequeueBuffer(), lockBuffer(), queueBuffer(). Essentially, it appears that EGL takes a free buffer out of native system's rotation, locks it for changing its contents, then puts back into queue for display.

Actual implementation of ANativeWindow for read device screen is in libs/ui/FramebufferNativeWindow.cpp . There's factory function to get its instance: android_createDisplaySurface().

All implementation details on buffers used are hidden in android_native_buffer_t type. It is also subclassed from android_native_base_t, its magic is "_bfr". Among simple things like width/height it contains buffer_handle_t, which leads in utero of vendor graphics driver. buffer_handle_t is native_handle*, and native_handle is a generic container for arbitrary number of fd's and pointers.

native_handle's are produced by gralloc vendor module, and that's exactly what FramebufferNativeWindow constructor does - it loads gralloc module, then uses it to open framebuffer and gralloc devices. It then allocates back and front buffers from gralloc devices with the size of the framebuffer. queueBuffer() method is implemented by calling framebuffer's post() method which well, shows the buffer on the screen.

18 Jan 2012 1:00am GMT

So, what it takes to upgrade Android on an arbitrary Android device (from user perspective)? What takes to run Linux in full-fledged mode? This boils down to few things:

Kernel porting

Upgrade kernel. This means forward-porting hardware support modules to a new kernel version. That's, when source code for such modules is available. Sometimes, it's not violating GPL (or tainting kernel, but who wants that? ;-) ). In an ideal world, that would all that's needed, but vendors don't like GPL, and try to move stuff outside of kernel. So, the list continues.



Bitblt acceleration porting

Next step is making sure that basic hardware acceleration works - accelerated bitblt/compositing (defining compositing as bitblt with alpha). This is actually pretty important step - without accelerated bitblt, Android with more or less big screen will run pretty sluggishly. Well, X Windows won't run too zippy either. Bitblt code in Android lives in /system/lib/hw/copybit.*.so and depends on gralloc.*.so from the same dir (* there is vendor/implementation identifier - Android support multiple, pluggable implementations). Needless to say, for a random device, source for these modules are not available - vendors don't have to provide it, it's Apache2-licensed, and very few choose to uphold OpenSource spirit nonetheless. So, if new Android version have changes the ABI for those modules, then oops - upgrade is "not possible" is layman terms. Of course, real men will immediately think about writing adapters, etc...

What about other X and other "foreign" windowing systems? They would need drivers/adapters too, and base all their low-level FB access based on Android's gralloc/bitblt/etc. model.

OpenGL ES porting

Last, least, but nonetheless. Curse of the modern world - OpenGL. You didn't have it on your Apple 2 (I mean Apple 2, yes, not what you thought about!) and everything was great, wasn't it? Apart from games you don't have time to play, what it's useful for? Yes, as soon as we'll stream videosignal directly into the brain, it will be useful for augmented reality, but I mean, *useful now*. They keep talking they added some hardware acceleration using OpenGL to the normal UI, then immediately say it didn't work that great, and depends on many things, because... Because OpenGL simply doesn't work that great, yeah. For example, even "accelerated", it's pretty slow, buggy, inconsistent across devices, etc, etc.

Anyway, thanks for listening to the rant. Let's de-emphasize usefulness of OpenGL, let's just take it as a challenge - vendors hacked it, so why can't hackers hack it? The basic idea is the same as with bitblt - there's an interface between closed vendor OpenGL ES implementation and Android. If interface changed, you're hosed. I mean, you write adapters. You also write adapters to make it talk with your windowing system of choice, and not Android. The core interfacing part of OpenGL ES/Android junction is EGL. How to deal about it is worth a separate post.

17 Jan 2012 6:40pm GMT

Recently I got new hack toy: cheap (well, depends) Chinese Zenithink ZT-180 tablet. This one seem to be (have been) pretty popular and hacker-friendly. Here's data about it:

• Vendor: http://zenithink.com/
• Product home page, ZT180-102 (it's the oldest in the product list, so soon will go to "Retired products" (== /dev/null))
• CPU: IMAPx200 (or IMAPx210, IMAPx220), ~1GHz
• GPU (SoC-builtin): GC600 (tentative)
• RAM: 512MB (Android boots with mem=384M)
• Bootloader: u-boot
• Kernel source from the vendor (github)
• Slatedroid forum announcement and discussion about the kernel release above
• Vendor toolchain
• Post saying that user yuray started upgrading kernel to 3.0.4. Following posts add more details, no source link provided.
• yuray also appears to be the author of ZT-180-Linux-Flash-Tool.
• Slatedroid ZT-180 Wiki
• More detailed hacking information

It seems that I've got vendor model ZT180_G2 (maybe, ZT180_G0).

Button combinations to hold during power on:

• Home+Power - Upgrade firmware from /sdcard/zt-update/
• Left arrow (of swing double-button)+Power - Boot with debug kernel from /sdcard/zt-debug/ . Debug kernel is booted and continues with the normal boot process.
• Right arrow (of swing double-button)+Power - Multiboot support, select one of 3 modes:
• • Android adb - kernel with ADB over USB support
  • Android mass storage - kernel with mass storage USB gadget support (tablet is presented as a mass storage when connected to host)
  • Other OS - WinCE

Random links:

• http://www.slatedroid.com/topic/10233-zenithink-zt-180-cpu-actually-infotmic-imap210-cpu/
• http://www.androidtablets.net/forum/infotmic-based/2354-infotmic-chips.html

17 Jan 2012 5:16pm GMT

Well, this really worth a cross-post. The way to stop Android GUI services is (under root of course):

UPDATE: Thanks to hint from StackOverflow: there're even simpler commands: "start" & "stop". Surprise.

16 Jan 2012 11:32pm GMT

The dedicated AM335x HDQ pin(s) aren't exposed on the beaglebone header, but there are enough GPIOs available to emulate one with the w1-gpio driver in linux. I connected a DS18B20+ to the beaglebone as shown in the picture above.
After patching the kernel and booting the update uImage:

root@beagleboneA3-0457:~# dmesg | grep w1
[    0.208956] w1-gpio connected to P8_3

root@beagleboneA3-0457:~# cat /sys/bus/w1/devices/28-00000256073a/w1_slave
b8 01 4b 46 7f ff 08 10 8a : crc=8a YES
b8 01 4b 46 7f ff 08 10 8a t=27500

With a friendlier output:

root@beagleboneA3-0457:~# cat /sys/bus/w1/devices/28-00000256073a/w1_slave | tail -n1 | awk -F= '{print $2/1000 " degrees Celsius"}'
27.687 degrees Celsius

The final tweak is to use some jumper wires to prevent the beaglebone from heating up the sensor:

root@beagleboneA3-0457:~# cat /sys/bus/w1/devices/28-00000256073a/w1_slave | tail -n1 | awk -F= '{print $2/1000 " degrees Celsius"}'
19.125 degrees Celsius

w1 patch

15 Jan 2012 12:20pm GMT

During my trip to Linaro Connect 2012q1 I want to buy Android tablet for myself. But this time I decided to spend more time on choosing one to not end with crap like Hannspree Hannspad which I bought half year ago.

Also situation on market changed. There are cheap tablets worth checking but there are also cheap crappy ones. So let me list what I checked so far.

As you see my requirements are more or less simple:

• dual core cpu (arm7)
• 512MB ram (1GB preferred)
• 1024×600 (or higher) resolution
• 7-8″ screen size (I had 10″ and it was too big)
• price below 300USD

During CES many vendors presented new tablets but I think that most of them will be released in Q2 or later. ASUS MeMo 370T looks nice for 250USD but it is not on market.

And I do not want 3G module in tablet - my phone has over 10GB of data limit to use for next months and so far I was not able to consume 1GB per month :)

Have I missed some devices? If yes then please share information in comments. Just remember that I do not want any of those NotionAdam/Viewsonic/Hannspad ones.

All rights reserved © Marcin Juszkiewicz
Want to buy Android tablet (again) was originally posted on Marcin Juszkiewicz website

13 Jan 2012 1:34pm GMT

Last Monday with it being a bank holiday I was invited out for a trip to the other side of Alston, starting from Allendale. I've wanted to ride the lanes over there for a while and this was my opportunity. I didn't fancy setting off early in the morning in the dark and trying to find fuel in Allendale so I took the bike in the van to the starting point. On the way, I found the conditions were getting colder the further inland I went and approaching Allendale, there was one junction where it was gently snowing with snow lying on the ungritted sections of road.

I managed to get there on time and eventually everyone was ready to set off. Everyone left apart from me and one other, I was playing my tail gunner role since I had a copy of the route. It was quickly clear we wouldn't be going anywhere whilst Stewie's chain was lying on the ground. Stewie has a reputation for breaking chains but not getting away from the van is a new record. Eventually the others noticed we weren't there and came back and we managed to get the chain repaired. We were off, really this time.

I have a reputation of not doing so well on ice covered tarmac so I'd decided I was going to take things very carefully. I was on the YZ which isn't really the ideal bike for those kind of conditions having too much power and totally knackered tyres (a dead mousse distorting the front and no tread on the back comparatively speaking). Sure enough as soon as we'd done the first lane we were onto ungritted country roads covered in a thin layer of sheet (black) ice. There was one nasty off camber T junction covered in ice which I did not enjoy at all. Coming around a corner I then found a piece of road with a couple of tight turns over a bridge, all covered in ice. This would have been bad enough (but manageable) but one of the group was lying in the road, as was his bike. Thankfully I wasn't carrying much speed but even then there wasn't any chance of stopping on the ice, or steering around the obstacles. At this point it helps to remember the kind of vehicle and its capabilities. I quickly concluded my only chance was to ride onto the 12″ strip of verge between the road and the wall and whilst that was covered in snow and heavily banked and undulating, chances were I would have enough traction to stop. Thankfully this proved correct. Ben got himself and the bike upright and we set off again. At this point I went past a couple of the group stopped halfway up a hill. There was too much ice around for me to fancy stopping too. I spent the next couple of miles of tarmac going slowly wondering where they were but they caught me up just as we found the rest of the group.

At this point I realised we were approaching Alston and were onto some trails I know. I only ever seem to see these ones in winter when they're covered in ice and they're heavily rutted making riding an interesting challenge. Rather than head into Alston, we bypassed it and did an interesting piece of trail which included a steep uphill section. Unfortunately one of the group was stopped half way up which meant everyone else had to stop. That person decided not to attempt the near vertical climb at the top and let someone else take the bike back down and take it at speed. I decided to just attempt it from stationary at the half way point which proved tricky and resulted in stalling the bike multiple times. The rear tyre's condition wasn't helping as it was just slipping. I was wary as the exit was onto a road with a parked car in the path if you applied too much speed/power. The first attempt ended up with the front wheel up, only to have the bike slide backwards back down it with me unable to grab the back brake, only keep the front locked solid which isn't a fun experience. I made it on the second attempt.

After the next trail, the group had disappeared. My GPS appeared to indicate the route was left so I followed it, only to realise I was heading in the wrong direction and the tracks were confused on the map. I turned around and found two group members looking for me. One U turned and headed back the way they'd come, the other continued past me. I sat in the middle and wondered what the heck I was supposed to do! We go that sorted out and found the rest of the group but I missed out on one of the trails. We then arrived in Alston and refueled. We were still on trails I'd done before but not for a long time. We wound our way up to Hartside Cafe, beyond which I've never ventured on green lanes. On road bikes, this marks the point the entrance to the Lake District and I've been there many times on tarmac though. We started down some very interesting lanes. There were a lot of muddy ruts and I was having a lot of difficulty keeping the YZ going in a straight line at any kind of speed.

We came across a group of horse riders (on tarmac) and slowly followed for a while until they pulled over onto some grass at a junction. The rest of the group went through but I was slightly behind having had trouble restarting the bike after stopping. As I approached and was about to pass, going slowly since I know how tricky these situations are, one of the horses reared up and set off down the road. I came to an instant stop despite the ice patches and waited as the rider controlled it and brought it back to the grass. At this point the horses were clearly getting nervous and it was spreading between them but I was able to carefully but quickly get off up the road past them, hopefully allowing the situation to diffuse. I can see these issues from both sides and I hope the horses/riders weren't too upset.

Next up was a road with a sign about a ford being washed out and impassible. To us this was interesting, we'll see. Upon arrival, it was clear there was a *lot* of fast moving water going through the core channel and it had been roped off with warning tape. We couldn't see any indication of depth and some of the group thought it was possible but I was of the opinion it was too deep/fast and after some discussion we reached that consensus. It'd be interesting to see it in summer.

Periodically, Ben's bike was cutting out, likely due to the cold and some form of carb icing type effect. It was frustrating as he'd have to sit for a while, then the bike would work just fine again. It was also proving a pain to kick start. I can sympathise with this after experiencing how draining kick starting the CRM was when I first started. At one point he'd dropped it in the mud and couldn't get it started and was obviously worn out so I gave it a go whilst he recovered a bit. It started first kick, I know how annoying it is for someone to do that :/.

At the end of one lane, we had a bit of confusion over the exact route to take with it turning out to be a drop down a hill, over a tiny stream, then through a much deeper ford crossing. On the drop, I managed to get a large tree branch stuck between the mud guard and the front wheel for which I had to stop and disentanhgle it. This isn't simple on a steep slope but I eventually managed. I only saw the last member of the group going through the ford but it was clear Ben had fallen in. I was given several pieces of conflicting advice about the best route over including mention of a large piece of old road which may or may not be in certain bits of the river but wasn't visible from where I was on the other side. Great. I set off through and about half way, it was clear I was riding on a piece of flat slab (old roadway?). So far so good but they'd said there was a problem? Sure enough, all of a sudden it became cracked, pointing upwards and then stopped with a deep drop (1ft+) off the end. At this point I accelerated a little and attempted a small jump off the end, as best as is possible off a slime covered piece of rock in water. Thankfully the bike then landed upright in the properly deep water with both wheels and I could quickly power out the river. Apparently Ben had attempted something similar but had lost balance coming off the slab, needed to put a foot down and slipped off. Far too easily done. We emptied out the drowned bike, then towed it to get it started.

We then had to stop in a village and wait whilst once again Stewie had to repair his chain. By this point we were running well behind schedule due to the stoppages and general slow progress made. There were some lovely relatively unused lanes we passed through. One memorable moment was coming to a shear decent, probably only a couple of metres in height which took some nerve to plunge the bike over. Again I was cursing the condition of the tyres on the muddy bits and couldn't carry any speed.

By this point time was against us as it was going to be getting dark. There certainly wasn't time for a lunch stop and we pressed on. We winded over the A686 (heads to Alston) taking some interesting lanes although I was still fighting tyres and going slowly. We then went up a trail that leads to hardside cafe which I've heard of but never done. I think I made the biggest hash of it I'd made all day, being unable to get traction anywhere even vaguely muddy. I ended up stalling and having to drop the bike into ruts to find stone to get momentum up the hillside. There is a steep climb at the side of the trail here and one group member did attempt it but only got halfway. The trouble then is getting back down safely. I decided not to bother given my experiences so far that day (and experiences of steep climbs going wrong on other occasions).

We then headed over to Garrigill at which point I hit reserve fuel (eek!). I did warn the rest of the group and thought Alston for a top up might be wise but Steve thought we'd make it back ok (he and another group member hit reserve too). We took the road over the top to Nenthead. I know this road well for various reasons and know that if there will be snow/ice anywhere, its on this road (17th highest road in Great Britain). Sure enough the whole thing was sheet ice. Making it the hill was bad enough. Once at the top, you then have the problem of getting down the other side. The only way I could do it was on the verge, being very mindful of the deep holes and drop offs (up to 6ft) in the verge. I was surprised to make it down there without some kind of incident, I was going very slowly/carefully. Apparently Steve did drop his bike at one point (I didn't for a change!).

There was one more lane and then it was tarmac back to Allendale. At this point I ran out of fuel entirely. Thankfully Paul came back to look for me when I disappeared and using a water bottle, I was able to share some of his fuel, enough to get me back to the van. Meanwhile, Stewie had also run out and was towed the last couple of miles.

Despite the issues, it was a great day out, one of the days I'll look back on with fond memories. I really enjoyed it and look forward to exploring more trails in that area when there is a bit more daylight.

13 Jan 2012 12:38pm GMT