Some problems upon kernel version jump

This forum is for users of Microchip MPUs and who are interested in using Linux OS.

Moderator: nferre

robbert
Posts: 3
Joined: Tue Dec 05, 2017 11:02 pm

Some problems upon kernel version jump

Tue Dec 05, 2017 11:36 pm

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:

Code: Select all

#define gpio_to_irq(gpio) (NR_IRQS_LEGACY + 32 + gpio)
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
Posts: 3
Joined: Tue Dec 05, 2017 11:02 pm

Re: Some problems upon kernel version jump

Wed Dec 06, 2017 2:45 pm

I found a difference in boot output that might be the cause of the problem:
Switching to clocksource tcb_clksrc
(on 3.14 as well as 3.10; the latter based on linux-3.10-at91)
while formerly, the output is:
Switching to clocksource pit
But perhaps, this is normal in later kernel versions.
blue_z
Location: USA
Posts: 1560
Joined: Thu Apr 19, 2007 10:15 pm

Re: Some problems upon kernel version jump

Thu Dec 07, 2017 3:46 am

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:

Code: Select all

obj-$(CONFIG_ARCH_AT91SAM9G45)	+= at91sam9g45.o at91sam926x_time.o at91sam9g45_devices.o sam9_smc.o

Whereas in the 3.14.12 Makefile, the build of this salient module depends on the configuration parameter CONFIG_AT91_SAM9_TIME:

Code: Select all

obj-$(CONFIG_AT91_SAM9_TIME)	+= at91sam926x_time.o
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.

robbert wrote:Is any documentation regarding migration steps for AT91 families with respect to kernel updates avaiable?
Other than the kernel release notes for each version, AFAIK no.

robbert wrote:As such, the Atmel maintainers forgot to remove the comment /* these pin numbers double as IRQ numbers, like AT91xxx_ID_* values */ from gpio.h.
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.

Regards
robbert
Posts: 3
Joined: Tue Dec 05, 2017 11:02 pm

Re: Some problems upon kernel version jump

Thu Dec 07, 2017 9:11 am

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.

Return to “Linux”

Who is online

Users browsing this forum: No registered users and 2 guests