On 06/07/2016 09:26 AM, Johnny Hughes wrote:

On 06/06/2016 02:32 AM, OM Ugarcina wrote:

...

Hello Guys,

I have a question on the roadmap for the CentosArm kernel . One of the reasons why people love Centos is the fact that it enjoys a longer support cycle than other distributions , which force the user to upgrade the whole OS every 6 months . But at the same time Centos backports important fixes , and improvements to the kernel to keep it up to date . So having a long term OS combined with kernel that is maintained is a very good reason for using Centos .

So I wanted to ask : What is the strategy for the arm kernels , is there going to be an active program to maintain the arm kernel ? I know that the regular Centos kernel is not viable for arm , it lacks a lot of support for arm hardware . We need a more modern version that is still long term supported but newer . My suggestion would be to take kernel 4.4 as the Centos arm main kernel . It has support for arm basic hw , and it is compatible with driver source code that is needed to be added for boards such as bananapi R1 (or also known as Lamobo R1) .

I my self am using Fedora's 4.4 kernels made for the fc22 line , but am expecting soon for that to disappear once fc24 comes out . And then no more kernel updates from fedora .

We are maintaining what was the Fedora 4.4 kernel spec, modified to keep things where they belong in CentOS-7 (and not in /usr/lib, etc.) AND using the kernel.org upstream tree.

We have a very beta attempt at that here:

http://armv7.dev.centos.org/repodir/arm-kernels/4.4.12-301/

We are still working out the kinks ... in this case, you must still edit /boot/extlinux/extlinux.conf by hand .. and you must remove the old kernel to make room for the new one. There is also a directory that contains 3 bootable kernels which looks to have a random name. That directory can be removed. ================================================

NOTE: If you remove the old kernel (due to size restraints) .. it is CRITICAL that you edit the extlinux.conf file correctly to use the new kernel. It should look like this with a default image:

#Created by RootFS Build Factory ui menu.c32 menu autoboot centos menu title centos Options #menu hidden timeout 60 totaltimeout 600 label centos kernel /vmlinuz-4.4.12-301.el7.armv7hl append enforcing=0 root=UUID=770af0f9-c7d9-4ae9-b024-1ba3c78d7550 fdtdir /dtb-4.4.12-301.el7.armv7hl initrd /initramfs-4.4.12-301.el7.armv7hl.img

None of those lines should wrap.

The UUID culd be different .. use the one already in your file.

The lines that need changes are the ones with the kernel version.

===============================================

We think that will a grubby update we may be able to automate the eltlinux.conf update, but we are still testing that.

ALso .. obviously this will not work for the Raspberry Pi devices as they have to use their own kernels and this one does not work there.

Note that there are also new xfsprogs and linux-firmware RPMs required and a new grubby is there, though that is still in testing.

The new xfsprogs is critical to prevent xfs corruption with new kernels .. see these bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1314605 https://bugzilla.redhat.com/show_bug.cgi?id=1314795

Thanks, Johnny Hughes

This would be the needed addition to config :

CONFIG_B53=y CONFIG_B53_SPI_DRIVER=y CONFIG_B53_PHY_DRIVER=y CONFIG_B53_SRAB_DRIVER=y CONFIG_B53_PHY_FIXUP=y CONFIG_SWCONFIG=y CONFIG_SWCONFIG_LEDS=y

On 13/06/16 13:59, mo.ucina wrote:

Hello Johnny

Would you be interested in adding in the 'linux-4.4.2-1.fc21.armv7hl.LR1' patch to your build which has the driver for the Bananapi R1 onboard switch (b53) . So far I have been adding this patch to the Fedora src rpm , and re-compiling the kernel every time . I would save a bit of work . I will attach the patch here . As far as the other steps you mentioned , I have been doing exactly that for the past few months .

Regards Milorad

On 06/12/2016 11:06 PM, mo.ucina wrote:

This would be the needed addition to config :

CONFIG_B53=y CONFIG_B53_SPI_DRIVER=y CONFIG_B53_PHY_DRIVER=y CONFIG_B53_SRAB_DRIVER=y CONFIG_B53_PHY_FIXUP=y CONFIG_SWCONFIG=y CONFIG_SWCONFIG_LEDS=y

On 13/06/16 13:59, mo.ucina wrote:

...

Hello Johnny

Would you be interested in adding in the 'linux-4.4.2-1.fc21.armv7hl.LR1' patch to your build which has the driver for the Bananapi R1 onboard switch (b53) . So far I have been adding this patch to the Fedora src rpm , and re-compiling the kernel every time . I would save a bit of work . I will attach the patch here . As far as the other steps you mentioned , I have been doing exactly that for the past few months .

Where did that patch come from?

What is the license of that patch?

On 06/21/2016 06:04 AM, mo.ucina wrote:

Hello Johnny,

The patch comes mostly from sources at OpenWrt , also from Denx.de . The license is GPL . Those two configs are very important they enable the switch and switch leds . There are several files dedicated to the switch portion .

Your patchlog should look like this :

patching file arch/arm/boot/dts/Makefile patching file arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts patching file drivers/net/phy/b53/b53_common.c patching file drivers/net/phy/b53/b53_mdio.c patching file drivers/net/phy/b53/b53_mmap.c patching file drivers/net/phy/b53/b53_phy_fixup.c patching file drivers/net/phy/b53/b53_priv.h patching file drivers/net/phy/b53/b53_regs.h patching file drivers/net/phy/b53/b53_spi.c patching file drivers/net/phy/b53/b53_srab.c patching file drivers/net/phy/b53/Kconfig patching file drivers/net/phy/b53/Makefil patching file drivers/net/phy/Kconfig patching file drivers/net/phy/Makefile patching file drivers/net/phy/swconfig.c patching file drivers/net/phy/swconfig_leds.c patching file include/linux/platform_data/b53.h patching file include/linux/switch.h patching file include/uapi/linux/Kbuild patching file include/uapi/linux/switch.h

I can apply the patch, but two things happen.

First, it impacts more than just armv7hl (it also effects all the other arches and I use this same file for all arches)

Second, it fails during the build on both armv7hl and i686 after install of the patch, though I will try again later this week.