티스토리 뷰

Embedded용 linux kernel은 대부분의 경우 SOC 업체에서 제공하는 kernel 을 사용하여 개발하여야 한다. 하지만 이런 커널은 대부분 SOC가 첫 출시된 시점의 kernel을 이용하여 porting 하였기 때문에 시간이 지나면 최신 커널과 버전 차이가 나는 단점이 있다. 


예를 들어 NXP(FreeScale) i.MX6의 제조사에서 제공하는 git kernel 을 보면 제공하는 버전(3.x.x 이상)이 다음과 같다.

  • 3.0.15, 3.0.35, 3.10.17, 3.10.53, 3.14.28, 3.14.38
  • 4.1.15

오늘자로 kernel.org 를 보면 최종 stable release 버전은 v4.7 (2016.7.24)이고, longterm maintenance release를 보면 아래와 같다.

Version

Maintainer

Released

Projected EOL

4.4

Greg Kroah-Hartman

2016-01-10

Feb, 2018

4.1

Sasha Levin

2015-06-21

Sep, 2017

3.18

Sasha Levin

2014-12-07

Jan, 2017

3.16

Ben Hutchings

2014-08-03

Apr, 2020

3.14

Greg Kroah-Hartman

2014-03-30

Aug, 2016

3.12

Jiri Slaby

2013-11-03

Jan, 2017

3.10

Willy Tarreau

2013-06-30

Oct, 2017

3.4

Li Zefan

2012-05-20

Sep, 2016

3.2

Ben Hutchings

2012-01-04

May, 2018


이 정도면 i.MX series는 2015.6에 릴리즈한 4.1 버전까지 제공하고 있으니까 상황은 좋은 편이다. 하지만 이는 최신 SOC 만 해당한다. 즉, i.MX5, i.MX6, i.MX7 만 해당되고, i.MX2, i.MX3 와 같이 오래전에 나온 SOC를 사용하는 경우에는 이 소스를 사용할 수 없다. i.MX31을 예로 들면 제공하는 kernel은 2.6.26 이다. 


개발 제품에 i.MX31을 사용한다고 가정해보자. 


직접 개발하는 부분은 제외하고, SW는 다음과 같은 모듈의 조합이 될것이다. 

  • SOC에서 제공하는 linux kernel
  • 사용하는 device 업체에서 제공하는 kernel driver와 application/library
  • 오픈소스 application과 library


이들 조합이 잘 맞는다면 큰 문제가 없지만, 서로가 요구하는 버전이 다르게 된다면 상당히 피곤해진다. 초기 기획단계에서 이런 문제를 찾았다면 다른 솔루션을 찾으면 될테지만 개발 도중에 이런 문제를 알게 된다면 프로젝트를 중단해야 할지도 모르는 심각한 상태가 될수도 있다.


예를 들면 다음과 같은 상황이라고 있을 수 있다.

  • 업체에서 제공하는 wi-fi driver와 모듈이 kernel 3.0 이상만 가능한 경우
  • Application에서 kernel 2.6.37 부터 제공하는 fanotify를 사용하여 작성되어 있는 경우 
  • Kernel 2.6.32 이상만 지원하는 Glibc 2.20+ 버전을 사용하여야 하는 경우 


이럴 경우 드라이버나 어플리케이션의 최신 기능을 포기하고 old version을 이용하거나, 아니면 kernel에 필요한 부분은 backporting 하여야 한다.


그래서 혹시나 해서 kernel.org 에 가서 official release 뒤져보니 일말의 희망이 보인다. 공식 커널의 arch/arm 폴더를 보면 최신 버전에서도 i.MX31을 지원하고 있다. 그래서 이걸 쓰면 되겠다 싶어서 받아다 빌드해서 올려보면 상황은 더 심각해진다. 기본 CPU core기능은 제대로 동작할지 몰라도, SOC 내부에 있는 주변기기나 power management와 같은 주요 기능들이 제대로 동작하지 않는다. 


여기서 의문이 들 것이다. SOC 업체에서는 왜 공식 커널에 자신들이 patch한 것을 보내서 적용하지 못하고 일부분만 적용시켜 결과적으로는 쓸수도 없는 상태로 방치하고 있을까?


이와 같은 이유는 kernel 소스의 doc/linux/MAINTENERS 파일을 보면 이해할 수 있다. 예를 들어 arch/arm 폴더의 소스는 아래와 같은 maintainer를 통해서 하여야 한다. 

ARM MFM AND FLOPPY DRIVERS

M: Ian Molton <spyro@f2s.com>

S: Maintained

F: arch/arm/lib/floppydma.S

F: arch/arm/include/asm/floppy.h


ARM PMU PROFILING AND DEBUGGING

M: Will Deacon <will.deacon@arm.com>

R: Mark Rutland <mark.rutland@arm.com>

S: Maintained

F: arch/arm*/kernel/perf_*

F: arch/arm/oprofile/common.c

F: arch/arm*/kernel/hw_breakpoint.c

F: arch/arm*/include/asm/hw_breakpoint.h

F: arch/arm*/include/asm/perf_event.h

F: drivers/perf/arm_pmu.c

F: include/linux/perf/arm_pmu.h


ARM PORT

M: Russell King <linux@armlinux.org.uk>

L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

W: http://www.armlinux.org.uk/

S: Maintained

F: arch/arm/


ARM SUB-ARCHITECTURES

L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

S: Maintained

F: arch/arm/mach-*/

F: arch/arm/plat-*/

T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git


다른 폴더는 각각의 maintainer를 통하여 commit 되어야 한다. ARM 관련 코드를 예로 들면 “The ARM Linux Project”의 mailing list로 오가는 메일을 보면 어떤 절차로 이루어 지고 있는지 알 수 있을 것이다.


정리해보면 NXP에서 해당 kernel을 official release에 반영하기 위해서는 각각의 모듈을 maintainer에 맞게 분리해서 따로 따로 절차를 밟아야 하고, 이때도 해당 reviewer 의 입맛에 맞게 patchset 을 나누어서 올려주어야 한다. 수정된 전체 소스를 모두 official kernel에 반영하는 것은 상당히 많은 노력이 필요한 일이 된다. 


결과적으로 SOC 업체는 대부분 적절한 official version에서 branch 해서 이에 자체 patchset을 반영하여 배포하고, 또 새로운 버전을 적용 할때마다 이와 같은 과정을 반복하게 된다. 그리고 이들 중 일부는 official kernel에 반영이 될 수도 있고, 안될 수도 있고…


SOC를 이용하여 제품을 개발할 때 신규 커널에 직접 해당 driver를 porting을  하는 것은 개발 일정상이나 리소스 면에서 불가능하다고 보아야 하고, 이 보다는 kernel의 버전은 고정하고, application 이나 driver의 버전을 낮추는 작업을 하거나, 필요하면 신규 kernel의 필요한 부분을 backporting하는 방법을 찾아야 할 것이다. 


또한 Backports project를 이용하여 driver부분 (특히 wireless)을 backporting하는 것도 방법일 수 있다. 이부분에 대해서는 나중에 설명할 예정이다. 

댓글
댓글쓰기 폼