I'm encountering some problems related to a jump from 2.6.33 to 3.14.12. Currently, I don't know how to get at91_tick interrupt operating.
Upon the pre-update state, proc/interrupts look like this:

1: 109196 AIC at91_tick, rtc0, ttyS0

With the update, I'm missing the tick interrupt.

The own board file has been based upon board-sam9m10g45ek.c. Manually, most of this reference board file changes have been transferred to the own boardfile. Other stuff has been updated by hand as well.
The current sam9m10g45ek board file calls other basic initialisation functions - which is for sure due to structural kernel changes.

Is any documentation regarding migration steps for AT91 families with respect to kernel updates avaiable?

BTW: Another severe problem led so serious trouble, too: Another interrupt numbering scheme. It was quite quickly found out that an offset NR_IRQS_LEGACY was introduced, but it was far more difficult to find out GPIO-related changes. After hours of investigation I ended up in defining a new macro in mach/gpio.h:

32 is the size of the AIC controller (a macro exists for this size, but I didn't find it afterwards). Formerly this offset was not needed, since the AT91_PIN_PXnn macros already had the offset. As such, the Atmel maintainers forgot to remove the comment /* these pin numbers double as IRQ numbers, like AT91xxx_ID_* values */ from gpio.h.

robbert wrote:I'm encountering some problems related to a jump from 2.6.33 to 3.14.12.

Aside from the choice of 3.14, why only patch level 12, when there's a 3.14.79?

robbert wrote:Currently, I don't know how to get at91_tick interrupt operating.

All you had to do was grep for "at91_tick" in the kernel source, and then you would learn that it's the name for the programmable interval timer, or PIT, implemented by module arch/arm/mach-at91/at91sam926x_time.c.
Then if you looked at the arch/arm/mach-at91/Makefile in 2.6.33, you'd see that this module is unconditionally built for SAM9G45-type boards:

Obviously you're not using the Device Tree, since that config parameter would automatically be selected for your board.
Whereas when DT is not used, that salient config parameter is not automatically be selected, nor is it even a selectable option.
Either by intent or oversight, the AT91 PIT driver is not a build option when not using the Device Tree.

Your complaint is several years too late, as version 3.14 is EOL, i.e. it is no longer maintained.
FWIW when you use the Device Tree, hardware interrupt numbers and GPIO interrupts are automatically converted to Linux interrupt numbers.

Bottom line, these issues would not occur if you used the Device Tree instead of a board file.

Thanks for your extensive reply. Meanwhile, I found out that the PIT timer is selected while deselecting the default timer options in the kernel configuration. Obviously, upon introduction of a new configuration feature anytime, it had been set active by default.

FYI: I realise that my complaint regarding pin numbers to IRQ is quite late. A backgrounder: a few years after having finished a project in the field of blackfin processors (ending up in kernel 3.0.8 ), I got (very recently) the job of updating an Atmel based product which is originated by another firm. So after a longer pause, I got to work upon this (while the at91-world is completely new for me). The concept of Device Tree instead of board file is new to me. It was my aim to do the execute with minimal risk. Whether the move from board file to DT would impose even lower risk of implementation problems, I don't know.

I selected 3.14 because of old board file removal later on. 3.14 was the only release family that also has RT-support patches before old board removal. Why .12 and not .79? I can't answer at the moment. Last friday, I determined this version after weighing pros and cons.

BTW: the reason of kernel update is: spuriously occurring errors with MCP2515 CAN-communication.
Meanwhile, the customer reports that the new kernel (running over 16 hours now) has resolved the problem.