Beaglebone으로 알아보는 linux kernel(3.10.x) programming

본 고에서는 open source hardware로 유명한 beaglebone black(BBB)을 이용하여 최신 linux kernel(3.10.x)에서 device driver를 어떻게 작성하는지에 관하여 정리해 보고자 한다.

목차는 다음과 같다.

1. BBB 개요
2. BBB용 kernel source download & build 절차 소개
3. Device Tree 소개
4. GPIO driver example - LED driver
5. i2c driver 구현 - Wii nunchuk i2c slave driver
6. UART adapter driver 구현
7. SPI driver 구현
8. USB driver 구현
9. SD/MMC driver 구현
References


1. BBB 개요

Beaglebone Black은 TI AM335x 1Gz ARM Cortex-A8 processor를 탑재하였으며, 45$라는 저렴한 가격의 opensource hardware(제 2의 라즈베리파이로 불림)로, 아래 site에서 자세한 내용을 확인할 수 있다.

http://beagleboard.org/Products/BeagleBone+Black

그림 1.1 BBB board hardware 개요

본 고에서 BBB를 선택하여 설명하는 이유는 다음과 같다.
1) Opensource hardware이므로, hardware 관련 자료(TRM 문서, SRM 문서, schematic 등)를 쉽게 얻을 수 있다.
2) Cortex-A8 기반의 ARM SoC를 채용하고 있으며, 최신 Linux kernel(3.10.x, 3.8.x)이 porting되어 있어, device tree 관련 내용을 테스트하기 용이하다.
  : device tree 관련 작업을 하는데 있어서 라즈베리파이 보다 배울 점이 많을 듯 보인다.
3) 여러 주변 장치를 맘껏 붙여 테스트해 볼 수가 있다(돈이 좀 들지만 ...).
4) 집에서도 테스트가 가능하다 .... 등등

대부분의 BBB 관련 내용이 사용자 영역에서의 programming(C, Python, Javascript 등 활용)에 촛점을 맞추고 있으나, 본 고에서는 kernel/device driver programming 관점에서 내용 전개를 진행할 예정이다. 이 글을 통해 최신 kernel(3.x) 환경에서 kernel/device driver programming이 어떻게 이루어지는지 확인해 보기 바란다.

그림 1.2 BBB LED 출력 화면(userspace에서 제어한 예제)

2. BBB용 kernel source download & build 절차 소개
이번 절에서는 Robert Nelson이 작성한 아래 site 내용을 토대로 BBB에 Debian 7(Wheezy)을 올리는 방법을 소개하고자 한다.

http://eewiki.net/display/linuxonarm/BeagleBone+Black

2.1) ARM Toolchain 설치
<생략>

2.2)  U-Boot bootloader source download & build 절차 소개
<생략>

2.3) Linux kernel source download & build 절차 소개
<생략>

그림 2.1 linux kernel source & build

2.4) Debian 7 용 rootfs download 절차 소개
<생략>

2.5) microSD card에 image 설치 절차 소개
<생략>

2.6) u-boot Environment txt 파일 소개
아래 내용은 u-boot가 booting에 사용하는 환경 설정 파일의 내용을 정리한 것이다. 아래 빨간색 글씨로 표시한 부분을 보면, kernel image와 fdt(flattened device tree - dtb로 보면 됨) image를 RAM에 별도로 loading한 후, bootz 명령으로 booting을 진행하고 있음을 알 수 있다.

#################################################################

$ cat uEnv.txt
kernel_file=zImage
initrd_file=uInitrd

loadzimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}

loadinitrd=load mmc ${mmcdev}:${mmcpart} 0x81000000 ${initrd_file}; setenv initrd_size ${filesize}

loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}

console=ttyO0,115200n8
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait fixrtc
mmcargs=setenv bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype} ${optargs}

#zImage:
uenvcmd=run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

#################################################################


3. Device Tree 소개

이 절에서 소개할 내용은 참고 문헌 [5]를 주로 참조하여 작성하였다. 따라서 자세한 사항을 원한다면 참고 문헌 [5]를 읽어 보기 바라며, 기초적인 내용 보다는 kernel programming에 필요한 관점에서 핵심적인 부분만을 추려 설명해 보고자 하였다. device tree 관련 기본 문법을 이해하고자 한다면, 아래 내용을 읽기 전에 필자의 아래 문서를 먼저 읽어 보기를 권한다.

http://www.kandroid.org/board/board.php?board=HTCDream&command=body&no=159

<Android_KernelHacks_Chapter4.pdf 참조>

[여기서 잠깐] Device Tree란 ?
단적으로 표현하면, 일정한 형식(문법)을 갖춘 텍스트를 이용하여, hardware(SoC, Board)를 기술하는 것을 말함.
이와 대비되는 기존의 방식으로 platform device 기반의 board 기술 방식(C coding)이 있었음.

<등장 배경 및 기존 방식의 문제점>
  1) SoC 혹은 board 별로 독자적인 code 구현
  2) 같은 SoC에서 파생된 보드 간에 상호 연관성이 있음에도 불구하고, 이를 전혀 고려하지 않고, 별도로 구현함.
  3) 따라서, 코드의 복잡도 및 코드량이 늘어는 문제 발생함.
     : arch/arm/mach-{YOURBOARD}/board-*.c 파일이 매우 복잡하고 난해함.
     : ARM linux 진영의 골칫거리. Linus Torvalds의 지적 !
  4) 보드 구성이 바뀌더라도 kernel code를 수정하지 않고, 동작할 수 있는 방식의 필요성 인식
  5) Device Tree는 기존에 다른 쪽(CPU)에서 사용하던 방식으로 ARM에도 채용하게 됨.
     : 새로 나오는 보드로 개발을 진행하여, linux kernel에 자신의 코드를 반영하고자 한다면, 반드시 device tree 기반으로 작업이 이루어져야 함.

<dts/dtsi 파일 compile 방법>

Source to blob:

$ scripts/dtc/dtc -I dts -O dtb -o /path/to/my-tree.dtb /path/to/my-tree.dts
Blob to source:
$ scripts/dtc/dtc -I dtb -O dts -o /path/to/fromdtb.dts /path/to/found_this.dtb

(*) Device Tree를 제대로 이해하기 위해서는(또는 이해하게 되면), 보드에 대한 전반적인 구조를 제대로 파악하고 있어야 한다(파악하게 된다).

우선 그림 3.1은  Device Tree를 이용하여, bootloader(예: u-boot)에서 DTB(Device Tree Blob - DT binary file)와 kernel image(uImage)를 RAM에 loading한 후, kernel booting을 진행하는 모습을 보여준다(기존 방식과의 차이는 별도 정리 안함).

그림 3.1 Device Tree를 이용한 커널 부팅 시, 메모리 맵

Device Tree에서 장치를 그림 3.2와 같이 노드로 표현하는데, 몇가지 주목해야할 부분만을 정리해 보면 다음과 같다.

<Device Tree에서의 장치 표현 방식 소개>
1) device는 노드로 표현하며(예: node@0), 각각의 노드는 다양한 속성 정보를 갖는다.
  : 각각의 device는 서로 다른 속성 정보(예: address, interrupt 정보 등)를 가짐.
  : 특히, compatible 속성은 device driver와 연결되는 부분으로, device driver code에서 관련 compatible string을 검색해 보면, 연결된 platform driver를 찾을 수 있음.

2) node@ 뒤에 붙는 숫자는 unit address로, 장치에 접근하기 위해 사용되는 1 차 주소이고, 노드
내의 reg 속성에 나열되어 있는 정보에 해당한다.
  : unit address가 필요한 이유는 동일한 장치(예: uart)가 여럿 존재할 경우, 이를 구분해가 위해서임.

3) 노드내에는 또다른 노드(자식 노드)가 올 수 있다.
  : device controller와 연결된 consumer(혹은 slave) device의 관계로 이해하면 될 듯.

4) 노드는 앞 부분에 별명(alias)을 붙일 수 있으며(예: node1), 다른 노드에서는 주로 이 별명을  활용하여 해당 노드를 참조하게 되는데, 이 때는 & 기호를 사용한다(예: &node1).
  : 별명을 사용하는 이유는, 주솟값 등이 붙어 있는 복잡한 노드에 대한 표현이 훨씬 간단해지기 때문임.
  : consumer device -> controller로의 접근을 표현(예: interrupt, clock, pinctrl 등)

5) 실세계에는 매우 다양한 장치(device)가 존재하므로, 자신만의 독자적인 device를 표현하기 위해서는 binding 문서(Documentation/devicetree/bindings)를 잘 정리해 두어야 한다(검증도 필요함).
  : 실제로 여러 dts[i] 파일 내용을 살펴 보면, 생각 보다 매우 복잡한 표현이 많이 있음.

그림 3.2 Device Tree 문법 - 기초

다음으로 device tree의 전체 구조를 살펴보기로 하자.

<Device Tree의 전체 구조 소개>
1) 확장자가 dtsi인 파일은 SoC를 표현하며, dts인 경우는 하위 보드를 표현한다.

2) 계층 구조를 유지하기 위해 하위 보드는 상위 보드 혹은 SoC의 dts를 상속 받을 수 있으며, include 문(혹은 C style의 #include 도 가능)을 사용하여 상위 보드 혹은 SoC를 위한 dts 파일을 포함시킬 수 있다(dts 파일 중간에서 포함시키는 것도 가능함).

3) 하위 보드에서 정의한 내용 중, 상위 보드의 내용과 중복되는 내용은 하위 보드에서 정의한 내용이 최종적으로 반영되며, 중복되지 않는 내용은 새로 추가(역시 반영됨)된다.
  : dts 내용을 보다 보면, 처음 부터 &node { } 로 표현된 부분이 있는데, 이는 앞서 dts[i] 파일에서 정의한 node를 overriding하는 것으로 이해하면 된다.

4) SoC의 구조를 보면, 대개 cpu, memory, system bus, system bus에 연결된 각종 device controller, device controller에 연결된 consumer device 들로 구성되어 있으므로, 이를 모두 node로 표현하면 된다.
  : ocp는 On Chip Peripheral을 의미하며, 각종 device controller를 이 부분에 나열해 주면 된다.

5) 각각의 node는 앞서 설명한 바와 같이, 다양한 속성(예: register, interrupt 등)이 있으므로 이를 적절히 표현해 주어야 하며, node 간에는 상호 연관성(예: interrupt, clock 등)이 있을 수 있으니, 역시 이를 잘 표현(&node 활용)해 주어야 한다.

그림 3.3은 dtsi 파일(SoC 용)과 이를 상속하는 dts 파일(board 용)이 하나의 dtb(실제 binary 파일이며, 편의상 text 형태로 보여주고 있음) 파일로 통합되는 과정을 보여주고 있다.

그림 3.3 Device Tree 상세 구조(1)

(다른 예이긴 하지만) 아래 그림 3.4는 imx28 SoC를 위한 device tree를 간략히 정리한 것이며, 그림 3.5는 imx28-evk 보드를 위한 device tree 파일을 정리한 것이다. arch/arm/boot/dts 디렉토리 아래에는 다양한 dts[i] 파일이 존재하므로 다양한 파일을 참조해 보는 것이 바람직할 듯 하다.

그림 3.4 Device Tree 상세세 구조(2) - SoC Device Tree

그림 3.5 Device Tree 상세 구조(3) -  Board Device Tree

Device Tree로 표현된 보드 description 내용은 커널 코드에서 참조할 수 있어야 하는데, 이와 관련 내용을 정리해 보면 아래 그림 3.6과 같다. 편의 상, 위의 그림 3.4 ~ 3.5의 내용이 아닌 일반적인 내용을 표현해 보았으나, 내용을 보면 바로 이해가 가능할 것으로 보인다. 그림 3.6에서 중요한 부분은 "vendor,soc-model1" 형태로 표현된 compatible 속성 부분으로, 위의 그림 3.5에 맞게 수정하려면, "fsl,imx28-evk" (보드 파일내의 top compatible 속성 정보)를 적어주면 된다. 그리고, 당연한 얘기지만 ,아래 코드는 arch/arm/mach-{YOURBOARD}/board_XXXX.c 파일을 구성하는 내용으로, 기존의 보드 파일에 비해 매우 간소화된 것을 알 수 있다.

그림 3.6 Device Tree 상세 구조(4) -  보드 파일 초기화 코드

다음으로 아래 그림 3.7은 apbh bus controller를 노드로 표현한 것으로, 여러가지 속성 정보와 노드들로 이루어져 있음을 알 수 있다. 이중, compatible = "simple-bus"이 좀 특별해 보이는데, "simple-bus"는 그 하위 노드(대개 device controller)가 동적으로 인식할 수 없는 장치(platform device)임을 뜻한다. 따라서, 그 아래에 기술된 여러 child node는 예전 기준으로 보면 platform device라 할 수 있으며, 이와 연결된 platform driver를 찾기 위해서는 그 node 내에 정의되어 있는 compatible 속성 정보를 활용하면 된다(불행히도 아래 예에서는 그 부분이 빠져 있음). 참고로, 아래 hsadc node의 compatible 속성을 child dts 파일에서 다른 내용으로 교체(override)한다면, 다른 platform driver가 연결되게 되므로, 이 방법을 이용한다면 자신이 만든 새로운 platform driver를 활용할 수 있게 될 것이다.

그림 3.7 Device Tree 상세 구조(5) - simple-bus

그림 3.8은 i2c0 controller 노드(아마도 위의 apbh node 내에 존재)를 표현한 것으로, compatible = " fsl,imx28-i2c" 속성을 갖고 있으며, 하위에 2개의 i2c slave 장치(sgtl5000, at24@51)가 연결되어 있음을 알 수 있다. i2c slave 장치는 반드시 address(i2c slave address) 속성을 지정해 주어야 하는데, 이는 reg = <주소> 속성을 통해서 가능하다. platform device의 경우와 비교해서 생각해 보기 바란다.

그림 3.8 Device Tree 상세 구조(6)  - i2c bus

그림 3.9는 위의 i2c0 controller에 해당하는 platform driver(drivers/i2c/busses/i2c-mxs.c)의 대략적인 모습을 보여준다. 앞서도 언급했다시피, 위의 device tree 내용과 platform driver를 연결해 주는 것은 "fsl,imx28-i2c" compatible 속성임을 알 수 있다.

그림 3.9 Device Tree 상세 구조(7)  - i2c bus controller driver 예

그림 3.10은 apbh bus에 연결된 interrupt controller(icoll)와 다른 장치(ssp0)에서 interrupt를 사용하는 방식을 표현하고 있다.
<Device Tree에서의 interrupt 표현 방식>
1) interrupt controller는 자신이 interrupt controller임을 알리기 위해 interrupt-controller; 문을 선언해 주어야 하며,
2) interrupt를 사용하는 장치에서는 자신이 사용하는 interrupt controller가 어떤 장치인지를 기술해 주어야 한다.
  : interrupt-parent = <&icoll>;
3) 또한, interrupt에 사용할 pin 번호를 지정해 주어야 한다.
  : interrupts = <96>
4) (드라이버 코드) 마지막으로 드라이버에서는 인터럽트를 등록(요청)해 주어야 한다.

그림 3.10 Device Tree 상세 구조(8) - interrupt

Device Tree에서 선언한 interrupt 부분을 driver 내에서 어떻게 사용하는지를 간략히 살펴 보면 다음과 같다. 편의상, 아래 내용은 위의 그림 3.10과는 무관한 다른 내용을 토대로 정리하였다.

<device tree 예>
  interrupts = < 0 59 1 >;
  interrupt-parent = <&gic>;

<driver code 예>
  irq = irq_of_parse_and_map(op->dev.of_node, 0);    //irq = 59가 들어옴.
  rc = request_irq(irq, xillybus_isr, 0, "xillybus", op->dev);

그림 3.11은 시스템 내에서 사용 중인 clock을 device tree로 표현한 것인데, 이를 보다 쉽게 이해하기 위해서는 SoC Technical Reference 문서를 참조하여, 전체적인 clock의 상관 관계를 먼저 파악하는 것이 필요하다.
<Device Tree에서의 clock 표현 방식>
1) 먼저 SoC 내의 clock을 모두 열거한다.
  : clock의 여러 속성, 특히 frequency 부분을 빼먹지 않는다.
2) 다음으로 각각의 장치(아래 그림 3.11에서는 cpu, timer, usb controller)에서 필요한 clock을 참조한다.
  : cpu@0의 경우, cpuclk 참조(=&cpuclk)
  : timer@20300의 경우, coreclk과 refclk 참조(= &coreclk, &refclk)
  : usb@52000의 경우, gateclk 참조(&gateclk)
3) (드라이버 코드) 마지막으로 드라이버에서는 clock을 사용하도록 요청해 주어야 한다.

그림 3.11 Device Tree 상세 구조(9) - clock(1)

그림 3.12 Device Tree 상세 구조(10) - clock(2)

Device tree 관련하여 마지막으로 살펴볼 내용은 pin control(혹은 pin muxing)에 관한 것이다. pin control(혹은 pin muxing)이 필요한 이유는 실제 패키지 밖으로 나와 있는 pin의 갯수 보다, 의도된 장치(i2c, uart, spi, gpio 등)의 수가 많아서, 이를 선택적으로 사용하기 위함이다. Device tree를 사용하기 이전에는 각각의 vendor 마다, 독자적인 방식을 사용하여 pin muxing 기능을 구현하였으나, Linus Walleij의 노력으로 linux 3.2 부터 pin control subsystem으로 통합되었다.

그림 3.13 Device Tree 상세 구조(11) - pin control subsystem(framework)

Device tree에서 pin control 관련 설정을 위해서는 크게 두단계의 과정이 필요하다.
<Device Tree에서의 pin control 표현 방식>
1) 사용하려는 pin의 목록을 정의한다(예: uart, i2c, spi 핀 등).
  : 위의 그림 3.13 처럼 mux를 기준으로 pin을 정의하는 것이 아니라, device(gpio, uart, spi, i2c 등)를 기준으로 pin을 정의하는 것임.
2) 위에서 정의한 pin을 실제 장치(예: gpio, uart)와 결합시킨다.
  : pinctrl-<number>에는 pin control 목록을 적어 주고(예: &uart0_pins_a),
  : pinctrl-names에는 pin control이름을 부여한다. 참고로, 이름이 "defaults"일 경우는 probe시 자동으로 pin control 요청을 해주게 된다.
3) (드라이버 코드) 마지막으로 드라이버 코드에서는 pin control을 요청해 주어야만 실제로 해당 pin을 원하는 용도로 사용할 수 있게 된다.

아래 그림 3.14는 leds(gpio)와 uart0 관련 pin control 설정 내용을 보여준다. 앞서 언급한 바와 같이 사용할 pin의 내역을 pinctrl@1c20800 node내에 선언한 후, 각각의 장치(uart0, leds)에서 이를 사용하기 위해 결합(pinctrl-0, pinctrl-names)하는 과정을 거치게 된다.

그림 3.14 Device Tree 상세 구조(12) - pin control(1)

그림 3.15는 BBB 보드에서 i2c0 controller를 위한 pin control 설정 과정에 대한 예를 보여주고 있다. pinctrl-single,pins 속성 부분을 제외하면, 앞서 설명한 내용과 대부분 동일한 방식으로 표현되어 있음을 알 수 있다. 이는 TI chip의 특성(drivers/pinctrl/pinctrl-single.c)과 관련된 부분으로, 이곳에는 각 핀의 <register, value> 쌍을 적어주게 된다. 참고로 아래 예에서는 register의 값으로 "(PIN_INPUT_PULLUP | MUX_MODE0)"와 같이 적어 주었으나, 실제로는 숫자 값(예: 0x70)을 적어주어야 한다. 또한 <register, value> 정보를 알기 위해서는 SoC TRM 문서를 참조해야 한다(이 부분이 조금 어렵게 느껴질 수 있다^^).

그림 3.15 Device Tree 상세 구조(13) - pin control(2)

Device Tree에서 기술한 pin control 내용은 실제로 platform driver의 probe 함수 내에서 요청(request)하는 과정을 통해서 실제로 사용할 수 있는 상태가 된다. 이는 다른 device 가령, clock, regulator 등을 사용하기 위해 get 함수를 호출해 주는 것과 같은 맥락이다. 아래 그림 3.16에서 이와 관련된 코드(pin control request)를 발췌해 보면 다음과 같다.

dev->pins = devm_pinctrl_get_select_default(&pdev->dev);

Pin control 관련 보다 구체적인 내용은 참고 문헌 [13-14]를 참조하기 바란다. 참고로, pin control 관련해서는 별도의 blog로 정리를 해 볼 예정에 있다^^.

그림 3.16 Device Tree 상세 구조(14) - pin control driver 사용 예

이상으로 Device Tree 관련하여 중요하다고 생각되는 부분만을 정리하여 보았다(빙산의 일각이기는 하지만^^). 여기까지 언급한 내용은 쉽다면 쉽고, 어렵다면 어려울 수 있겠는데, 실제로 device tree를 제대로 이해하기 위해서는 보단 많은 관련 문서 및 실제 dts[i] 파일을 검토해 보아야 할 것으로 보인다. 처음에는 한눈에 device tree의 concept가 들어오지 않을 것이나, 반복적으로 관련 글을 읽어 보고, 아래 소개하는 실제 코딩 과정을 거치다 보면, 그 의미와 사용법이 보다 명확해 질 것으로 믿는다.

끝으로, device tree 관련하여 좋은 글을 많이 정리해 주신 Free Electrons의 Thomas Petazzoni 님께 감사의 마음을 전한다 - Thomas and free electrons guys ! Thanks you so much for your great documents[5-10].


4. GPIO driver example - LED driver

이번 절에서는 device tree 기반으로 LED(GPIO) 드라이버를 어떻게 작성하는지에 관하여 설명하고자 한다. 먼저 기존의 gpio led platform device 코드를 살펴봄으로써, device tree로 전환 시, 차이점을 파악해 볼 것이며, 후반부에서는 device tree를 사용하는 gpio led platform driver 코드를 분석하므로써, 드라이버 내에서 device tree를 어떤식으로 접근하는지를 이해하도록 해 볼 것이다.

[여기서 잠깐 !] BBB의 GPIO와 Pinmux에 대해 
AM335x에는 4개의 GPIO bank(chip)가 존재하며, 각각의 GPIO bank는 32개의 GPIO 패드로 구성되어 있다. 하나의 GPIO 패드는 GPIO[chip]_[pin] 와 같이 표현되는데, 실제 사용되는 pin 번호는 아래의 산술식을 통해 계산해내야 한다.

GPIO numuber = chip * 32 + pin

예를 들어, GPIO1_21은 1*32 + 21 = 53 이므로, 이는 GPIO53을 뜻하는 것으로 이해하면 된다. 아래 예는 익히 알고 있는 gpio API를 활용하여, GPIO 53을 통해 LED를 켜는 간단한 예를 보여준다.

////////////////////////////////////////////////////////////

#define GPIO1_21    53

static int __init gpio_led_init(void)
{
    ...
    err = gpio_request(GPIO1_21, "USR 1 LED");
    gpio_direction_output(GPIO1_21, 0);
    msleep(1000);
    gpio_direction_output(GPIO1_21, 1);
    ...
}

////////////////////////////////////////////////////////////

다음으로, AM335x에서도 pin 부족 문제를 해소하기 위해 pinmux 기능을 사용한다. AM335x TRM 문서를 참조하면 알 수 있듯이, GPIO를 포함한 몇몇 device(주로, uart, i2c, mmc, spi, lcd 등)는 pinmux 기능을 사용하게 되며, 8가지 모드(mode0 ~ mode7)에 따라 서로 다른 장치의 pin이 선택되게 됨을 알 수 있다.
////////////////////////////////////////////////////////////////////////////////////////////////////////////


(다시 원래의 문제로 돌아와서)BBB에는 사용자를 위한 4개의 파란색 led(usr0 ~ usr3)가 존재하며, 각각은 GPIO1_21(=GPIO 53), GPIO1_22(GPIO 54), GPIO1_23(GPIO 55), GPIO1_24(GPIO 56)를 통해 제어되는데, 이들 핀은 모두 pinmux 설정을 통해 선택된 후에야 사용이 가능하다.

그림 4.1 Platform device 기반의 GPIO LED 코드 예

따라서, 먼저 4개의  LED(gpio)에 대한 pin mux 설정을 위한 배열을 선언하고, 이후 boneleds_init( ) 함수에서 setup_pin_mux() 함수를 호출해 줌으로써 pin muxing을 위한 초기화 작업이 진행되게 되는 것을 볼 수 있다. 참고로, pin mux 배열내에 선언된 내용은 각 pin에 대한 정보(실제로는 register 주소임 - offset 번지)와 register 값(mode7 | pin output)임을 유추할 수 있다.


static struct pinmux_config bone_pin_mux[] = {
    {"gpmc_a5.rgmii2_td0", OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT}, // USR0
    {"gpmc_a6.rgmii2_tclk", OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT}, // USR1
    {"gpmc_a7.rgmii2_rclk", OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT}, // USR2
    {"gpmc_a8.rgmii2_rd3", OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT}, // USR3
    ...
    {NULL, 0},
};

static void boneleds_init(int evm_id, int profile )
{
    ...
    setup_pin_mux(bone_pin_mux);
    err = platform_device_register(&bone_leds_gpio);
    ...
}


이미 독자 여러분이 알고 있는 바와 같이, 최종적으로 platform_device_register() 함수를 호출해 줌으로써 platform device가 등록되게 된다.


다음으로 그림 4.2는 앞서 설명한 내용을 device tree 형태로 전환한 것으로, device tree 내에서 pinmux를 표현하기 위해서는 앞서 3절의 후반부에서 설명한 바와 같이, 크게 2단계의 과정을 거치게 된다.

1) pin mux 설정을 위한 pin 목록 선언(userled_pins 노드)
  : 어떤 pin을 pin mux의 용도로 사용할지를 언급하는 것임.
2) 실제 led 장치(gpio-leds 노드)에서 pinmux에 사용할 pin을 자신과 결합시킴
   : pinctrl-names, pinctrl-0 부분 선언해 주어야 함.
   : led 노드에서 해당 gpio bank를 참조하도록 설정해 줌.
      -> gpios = <&gpio2 21 0>;
      -> gpios = <&gpio2 22 0>;
      -> gpios = <&gpio2 23 0>;
      -> gpios = <&gpio2 24 0>;
  => 참고로, 여기서 gpio1이 아니라, gpio2 노드를 참조하는 이유는, am33xx.dtsi 파일에서 gpio bank 명을 gpio1 ~ gpio4로 표현했기 때문임.

그림 4.2 Device Tree 기반의 GPIO LED 

마지막으로 device tree 기반의 LED platform driver의 구조를 분석해 봄으로써 이 절을 마무리하도록 하자. 먼저 그림 4.3 코드에서 가장 먼저 주목해야 하는 내용은 compatible = "gpio-leds" 부분이라고 말할 수 있다. 그 이유는 이 값을 통해 앞서 설명한 device tree의 gpio-leds 노드와 led platform driver가 연결되게 되기 때문이다.

<TODO - 추가 설명 필요함>

그림 4.3 GPIO LED platform driver 구조

[여기서 잠깐 !] of_XXXX( ) 함수에 대해 

우선 of는 Open Firmware를 뜻하며, driver 내에서 device tree 관련 정보를 얻어오기 위해서는 of_XXXX( ) 형태의 함수를 사용해야 한다. 이 함수들은 drivers/of 디렉토리에 구현되어 있는데, 예제를 통해서 of 함수의 사용법을 간략히 정리해 보면 다음과 같다. platform device 시절의 함수와 비교해 보면서 아래 내용을 살펴보기 바란다.

<device tree 예>

xillybus_0: xillybus@50000000 {

     compatible = "xlnx,xillybus-1.00.a";

     reg = < 0x50000000 0x1000 >;

     interrupts = < 0 59 1 >;

     interrupt-parent = <&gic>;

     xlnx,max-burst-len = <0x10>;

     xlnx,native-data-width = <0x20>;

     xlnx,slv-awidth = <0x20>;

     xlnx,slv-dwidth = <0x20>;

     xlnx,use-wstrb = <0x1>;

} ;

<platform driver 초기화 코드 예>

static struct of_device_id xillybus_of_match[] __devinitdata = {

    { .compatible = "xlnx,xillybus-1.00.a", },

    {}

};

MODULE_DEVICE_TABLE(of, xillybus_of_match);

[ ... ]

static struct platform_driver xillybus_platform_driver = {

     .probe = xilly_drv_probe,

     .remove = xilly_drv_remove,

     .driver = {

          .name = "xillybus",

          .owner = THIS_MODULE,

          .of_match_table = xillybus_of_match,

     },

};

<probe() 함수 내 - sanity checking 함수>

static int __devinit xilly_drv_probe(struct platform_device *op)

{

     const struct of_device_id *match;

     match = of_match_device(xillybus_of_match, &op->dev);    //sanity check !

     if (!match)

          return -EINVAL;

     ...

<probe() 함수 내 - resource 정보 추출 함수>

int rc = 0;

struct resource res;

void *registers;

rc = of_address_to_resource(&op->dev.of_node, 0, &res);  //resource 정보 획득

if (rc) {

     /* Fail */

}

if (!request_mem_region(res.start, resource_size(&res), "xillybus")) {

     /* Fail */

}

registers = of_iomap(op->dev.of_node, 0);    //register 정보 추출

if (!registers) {

     /* Fail */

}

<probe() 함수 내 - 인터럽트 번호  추출 함수>

irq = irq_of_parse_and_map(op->dev.of_node, 0);

rc = request_irq(irq, xillybus_isr, 0, "xillybus", op->dev);

<probe() 함수 내 - 속성 값 추출 함수>

void *ptr;

int value;

ptr = of_get_property(op->dev.of_node, "xlnx,slv-awidth", NULL);

if (!ptr) {

    /* Couldn’t find the entry */

}

value = be32_to_cpup(ptr);

//////////////////////////////////////////////////////////////////////////////////////

이렇게 해서 간략하게 나마 device tree 방식을 사용하는 GPIO LED 드라이버에 관하여 살펴 보았다.

5. i2c driver 구현 - Wii nunchuk
내용이 너무 길어져 아래에 별도로 정리하였다.

http://slowbootkernelhacks.blogspot.kr/2014/03/device-tree-i2c-programming.html

6.  UART adapter driver 구현
내용이 너무 길어져 아래에 별도로 정리하였다.

http://slowbootkernelhacks.blogspot.kr/2014/03/device-tree-uart-programming.html

7. SPI driver 구현
내용이 너무 길어져 아래에 별도로 정리하였다.

http://slowbootkernelhacks.blogspot.kr/2014/04/device-tree-spi-programming.html

8. USB driver 구현
<TODO>


9. SD/MMC driver 구현
<TODO>


최근(2017.05.26)에 작성한 아래 내용도 함께 참조해 주기 바란다.
<Yocto 환경에서의 linux 4.x device driver programming>
http://slowbootkernelhacks.blogspot.kr/2017/05/yocto-project-linux-device-driver.html

References
<BBB>
1) BeagleBone Black System Reference Manual Revision B, January 20, 2014, Gerald Coley

2) AM335x ARM® CortexTM-A8 Microprocessors(MPUs) Technical Reference Manual, Texas Instruments

3) Getting Started With BeagleBone, by Matt Richardson, Maker Media

4) http://eewiki.net/display/linuxonarm/BeagleBone+Black - Robert Nelson

<Device Tree & Overlay>
5) Device Tree for dummies.pdf - Thomas Petazzoni, Free Electrons

6) Linux kernel and driver development training Lab Book, Free Electrons

7) Linux Kernel and Driver Development Training, Free Electrons

8) Linux kernel: consolidation in the ARM architecture support, Thomas Petazzoni, Free Electrons,

9) ARM support in the Linux kernel, Thomas Petazzoni, Free Electrons

10) Your new ARM SoC Linux support check-list! Thomas Petazzoni, CLEMENT, Free Electrons,

11) Supporting 200 different expansionboards - The broken promise of device tree, CircuitCo.

12) The Device Tree: Plug and play for Embedded Linux, Eli Billauer

13) Introduction to the BeagleBone Black Device Tree, Created by Justin Cooper

<Pin Control>

14) Pin Control Sybsystem – Building Pins and GPIO from the ground up, Linus Walleij

15) PIN CONTROL OVERVIEW, Linaro Kernel Workgroup, ST-Ericsson, Linus Walleij

<Wii Nunchuk>
16) ZX-NUNCHUK(#8000339) Wii-Nunchuk interface board