Linux Kernel Hacks

안정성을 넘어서 이제는 대세로~

이상의 과정을 통해 최종적으로 연결된 bus core(예: USB core), controller(예: USB adapter) 및 device(예: USB device) 간의 관계를 하나의 그림으로 표현하면 다음과 같다.

[그림 2.4] USB bus core/adapter/device 관계도 [출처 - 참고문헌 9]

이와 같은 각종 device(controller & consumer devices)는 부팅 시에 initialization level에 의거하여 device list에 추가되고, 초기화되는 과정을 거치게 된다.

[그림 2.5] Linux kernel initialization sequence

📌 실제로 이 부분도 할말이 아주 많은 부분이나, (서운하지만) 그림 하나로 퉁치고 넘어가기로 한다. 😋

struct device {
    /** Name of the device instance */
    const char *name;
    /** Address of device instance config information */
    const void *config;
    /** Address of the API structure exposed by the device instance */
    const void *api;   //application code가 사용하는 API 함수
    /** Address of the common device state */
    struct device_state *state;
    /** Address of the device instance private data */
    void *data;
}

위의 struct device의 각 필드는 (드라이버 개발자에 의해) 아래와 같은 내용으로 채워지게 된다.
struct your_dev_config {
    // memory mapped IO 주소, IRQ line number, device 관련 물리적인 정보 등이 포함됨.
}

static struct subsystem_api your_api_funcs = {
    // application에서 driver 정보를 추출하고자 할 때 사용하는 API
    .do_this = my_driver_do_this,
    .do_that = my_driver_do_that
};

struct your_dev_data {
    // device 관련 data 정보를 임시로 담아두고자 할때 사용하는 buffer 등을 정의
}


[그림 2.6] Zephyr device driver model [출처 - 참고문헌 1]

끝으로, device tree 관련 내용은 아래과 같은 절차를 거쳐 compile 과정에서 C #define 문으로 자동 전환되게 되며, device driver는 이 내용(혹은 이를 이용한 macro)을 사용하여 driver code를 완성하게 된다.

zephyr/build/zephyr/include/generated/zephyr/devicetree_generated.h

[그림 2.7] device tree로 부터 C header file 생성 과정 [출처 - 참고문헌 13]

[그림 4.6] STM32 Nucleo-L432KC 보드(우측 하단)와 ADXL345 보드(상단) 연결

/* my_driver.c */
#include <zephyr/drivers/some_api.h>

/* Define data (RAM) and configuration (ROM) structures: */
struct my_dev_data {
     /* per-device values to store in RAM */
};
struct my_dev_cfg {
     uint32_t freq; /* Just an example: initial clock frequency in Hz */
     /* other configuration to store in ROM */
};

/* Implement driver API functions (drivers/some_api.h callbacks): */
static int my_driver_api_func1(const struct device *dev, uint32_t *foo) { /* ... */ }
static int my_driver_api_func2(const struct device *dev, uint64_t bar) { /* ... */ }
static struct some_api my_api_funcs = {
     .func1 = my_driver_api_func1,
     .func2 = my_driver_api_func2,
};

위의 내용을 기초로하여, adxl345 device driver code를 대략적으로 작성해 보면 다음과 같다.

struct adxl345_dev_config {

const union adxl345_bus bus;

adxl345_bus_is_ready_fn bus_is_ready;

adxl345_reg_access_fn reg_access;

static const struct sensor_driver_api adxl345_api_funcs = {

.sample_fetch = adxl345_sample_fetch,

.channel_get = adxl345_channel_get,

struct adxl345_dev_data {

unsigned int sample_number;

int16_t bufx[ADXL345_MAX_FIFO_SIZE];

int16_t bufy[ADXL345_MAX_FIFO_SIZE];

int16_t bufz[ADXL345_MAX_FIFO_SIZE];

#define DT_DRV_COMPAT adi_adxl345

static bool adxl345_bus_is_ready_i2c(const union adxl345_bus *bus)

return device_is_ready(bus->i2c.bus);

static int adxl345_reg_access_i2c(const struct device *dev, uint8_t cmd, uint8_t reg_addr,

uint8_t *data, size_t length)

const struct adxl345_dev_config *cfg = dev->config;

if (cmd == ADXL345_READ_CMD) {

return i2c_burst_read_dt(&cfg->bus.i2c, reg_addr, data, length);

return i2c_burst_write_dt(&cfg->bus.i2c, reg_addr, data, length);

static int adxl345_sample_fetch(const struct device *dev,

enum sensor_channel chan)

static int adxl345_channel_get(const struct device *dev,

enum sensor_channel chan,

struct sensor_value *val)

static const struct sensor_driver_api adxl345_api_funcs = {

.sample_fetch = adxl345_sample_fetch,

.channel_get = adxl345_channel_get,

2024년 11월 13일 수요일

Zephyr RTOS Programming

이번 시간에는 오랫 만에 리소스 제한(부족) 장치(resource contrained device)를 가지고, 실제로 Zephyr RTOS programming을 어떻게 하는지 소개해 볼까 한다. 좀 거창하지만, 실전 Zephyr RTOS programming 시간이 되겠다~ 😎

Zephyr RTOS의 bootling flow와 관련해서는 특별히 아래 문서의 내용이 아주 훌륭하여, 여기에 옮겨 보았다. 😍https://www.youtube.com/watch?v=tAH5fy0rSo4&ab_channel=TheLinuxFoundation📌 이 글의 원저자이신 David Leach 님에게 경의를 표한다. 👍

참고로, 아래 내용은 필자가 3년전에 분석했던 내용으로, 함께 참조해 주시기 바란다. 😓[그림 1.1] Zephyr booting flow - 대략적인 코드 흐름 분석

https://slowbootkernelhacks.blogspot.com/2020/11/zephyr-rtos-project.html

[그림 2.1] Linux device driver model [출처 - 참고문헌 11]

2.2 Zephyr device driver model한편, Zephyr는 resource가 제한되어 있는 환경을 고려하여, linux 처럼 복잡한 구조 보다는 아래와 같은 단순한 data structure를 이용하여 device driver를 구현한다.

실제 device driver에는 driver code를 시작하는 init( ) 함수가 있으며, driver registration(list에 등록을 의미함)을 하기 위해서는 아래와 같은 macro를 사용한다. 아래 macro 호출 시, 앞서 정의한 config, api, data pointer 정보도 함께 전달된다.

📌 주요 device driver code를 살펴 보면, 코드 마지막 부분에 위와 같은 macro를 사용하는 내용이 보인다.

각각의 device를 표현하는 struct device 내용은 initialization level(level, prio 값)에 입각하여 RAM section에 적절히 배치되고, 실제 동작 시 활용된다.

[그림 2.6] Zephyr device driver model [출처 - 참고문헌 1]

지금까지, zephyr RTOS의 device driver model에 관하여 간략히 살펴 보았다.

4. STM32 Nucleo L432KC Board - I2C Device이번에는 ADXL345 3축 가속도(Accelerometer) 센서용 i2c device driver와 이를 사용하는 application을 구현하는 방법을 소개해 보고자 한다.

[그림 4.1] ADXL345 3축 가속도(Accelerometer) 센서 브레이크아웃 보드

📌 주의: ADXL345 보드는 i2c와 spi 겸용으로 설계되어 있다.

[그림 4.2] ADXL345 I2C connection [출처 - 참고문헌 18]

📌 주의: ADXL345를 i2c mode로 사용하려면 CS pin을 Vcc(3.3V)와 연결해 주어야만 한다.

[그림 4.3] STM32 Nucleo-L432KC CN4 pinout [출처 - 참고문헌 6]

📌 주의: (매뉴얼을 보니) A4, A5 pin이 solder bridge SB16, SB18에 의해 PB7, PB6로 연결되어 있다.

<Nucleo-L432KC 보드> <ADXL345>CN4 2번 pin - GND ------- GNDCN4 14번 pin - Vcc(3.3V) ------- VCC(3.3V)CN4 7번 pin(PA6) - I2C1 SCL ------- SCLCN4 8번 pin(PA5) - I2C1 SDA ------- SDACN3 4번 pin - GND ------- SDO (ALT Address)다른 Board Vcc(3.3V) ------- CS

📌 처음에는 PB7(SDA), PB6(SCL)에 연결해야 하나 생각했으나, 테스트 결과, 원래 pin 즉, PA5, PA6에 연결하는 것이 맞았다.

📌 Target board에 ADXL345 CS pin을 연결할 여분의 VCC(3.3V) 확장 pin이 없으므로, 다른 board를 하나 준비한 후, 그 board에 연결해야 할 것 같다. 😱

📌 좌측 하단의 보드는 Vcc(3.3V)용 연결 목적으로만 사용된다.

📌 (참고) 나중에 다시 확인해 보니, CS pin을 굳이 VCC(3.3V)에 연결하지 않아도 동작한다. 😓

4.2 device driver 작성먼저 device tree 파일에 adxl345 sensor를 위한 node 정보를 추가해 보도록 하자(실제로 이 내용은 나중에 overlay 파일로 분리될 것임).

&i2c1 { pinctrl-0 = <&i2c1_scl_pb6 &i2c1_sda_pb7>; pinctrl-names = "default"; clock-frequency = <I2C_BITRATE_FAST>; status = "okay"; adxl345: adxl345@53 { compatible = "adi,adxl345"; reg = <0x53>; status = "okay"; };};

📌 device tree의 compatible = "adi,adxl345"에 해당하는 내용이다. (주의)#define 문에서는 ,(comma) 대신에 _(underscore)로 교체되어 표기한다.

📌 i2c read/write 함수를 정의한다.

📌 sample_fetch()와 channel_get() 함수는 application을 위한 창구(API) 역할을 한다.

📌 중요: compatible DT_DRV_COMPAT(예: adi_adxl345) 값과 일치하는 device tree 내의 node(단, status="okay"인 경우만 해당)에 대해 device(struct device)를 초기화(instance화)하는 역할을 담당하는 macro이다.

📌 적당한 예제 코드를 찾아 복사하거나, 일일이 새로 만든다.

<app.overlay>/* * Copyright (c) 2024 Chunghan Yi<chunghan.yi@gmail.com> * * SPDX-License-Identifier: Apache-2.0 */&i2c1 { status = "okay"; adxl345: adxl345@53 { compatible = "adi,adxl345"; reg = <0x53>; status = "okay"; };};

📌 adxl345의 i2c slave address가 0x53인 이유는 아래 posting(2장)을 참고하도록 하자.

c) prj.conf 파일 수정<prj.conf>CONFIG_STDOUT_CONSOLE=yCONFIG_SENSOR=yCONFIG_ADXL345=y

📌 CONFIG_I2C=y는 굳이 추가하지 않아도 자동으로 zephyr/build/zephyr/.config 파일에 추가된다.

d) main code 작성application main code는 다음과 같다.[그림 4.8] adxl345 application main.c code(별 내용은 없지만) Source code는 아래 위치에 올려 두었다. 😘https://github.com/ChunghanYi/zephyr-examples/tree/master/samples/sensor/adxl3454.4 build & run & debugging

지금까지 만든 내용을 실제로 target board에서 돌려 보도록 하자.

📌 정확한 3축 센서 값을 출력해야 하나, driver 구동 과정에 대한 설명이 목적인 만큼 일단 pass~ 😋

5. BLE Application - TODO이번 장에서는 nRF52840 dongle board를 기반으로 zephyr BLE application을 만드는 과정을 소개하고자 한다.To be continued ...

6. References<zephyr>[1] https://docs.zephyrproject.org/latest/[2] Zephyr Project: RTOS Startup and Initialization Flow, David Leach, NXP Semiconductors ELC 2021 *****[3] Zephyr RTOS Embedded C Programming Using Embedded RTOS POSIX AP, Apress, Andrew Eliasz

<adxl345 sensor>[17] https://www.analog.com/en/products/adxl345.html#documentation[18] https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf[19] And, Google~Slowboot

Zephyr RTOS의 bootling flow와 관련해서는 특별히 아래 문서의 내용이 아주 훌륭하여, 여기에 옮겨 보았다. 😍
https://www.youtube.com/watch?v=tAH5fy0rSo4&ab_channel=TheLinuxFoundation
📌 이 글의 원저자이신 David Leach 님에게 경의를 표한다. 👍

참고로, 아래 내용은 필자가 3년전에 분석했던 내용으로, 함께 참조해 주시기 바란다. 😓
[그림 1.1] Zephyr booting flow - 대략적인 코드 흐름 분석

2.2 Zephyr device driver model
한편, Zephyr는 resource가 제한되어 있는 환경을 고려하여, linux 처럼 복잡한 구조 보다는 아래와 같은 단순한 data structure를 이용하여 device driver를 구현한다.

4. STM32 Nucleo L432KC Board - I2C Device
이번에는 ADXL345 3축 가속도(Accelerometer) 센서용 i2c device driver와 이를 사용하는 application을 구현하는 방법을 소개해 보고자 한다.

<Nucleo-L432KC 보드> <ADXL345>
CN4 2번 pin - GND ------- GND
CN4 14번 pin - Vcc(3.3V) ------- VCC(3.3V)
CN4 7번 pin(PA6) - I2C1 SCL ------- SCL
CN4 8번 pin(PA5) - I2C1 SDA ------- SDA
CN3 4번 pin - GND ------- SDO (ALT Address)
다른 Board Vcc(3.3V) ------- CS

4.2 device driver 작성
먼저 device tree 파일에 adxl345 sensor를 위한 node 정보를 추가해 보도록 하자(실제로 이 내용은 나중에 overlay 파일로 분리될 것임).

&i2c1 {
pinctrl-0 = <&i2c1_scl_pb6 &i2c1_sda_pb7>;
pinctrl-names = "default";
clock-frequency = <I2C_BITRATE_FAST>;
status = "okay";
adxl345: adxl345@53 {
compatible = "adi,adxl345";
reg = <0x53>;
status = "okay";
};
};

<app.overlay>
/*
* Copyright (c) 2024 Chunghan Yi<chunghan.yi@gmail.com>
*
* SPDX-License-Identifier: Apache-2.0
*/

&i2c1 {
status = "okay";
adxl345: adxl345@53 {
compatible = "adi,adxl345";
reg = <0x53>;
status = "okay";
};
};

c) prj.conf 파일 수정

<prj.conf>
CONFIG_STDOUT_CONSOLE=y
CONFIG_SENSOR=y
CONFIG_ADXL345=y

5. BLE Application - TODO
이번 장에서는 nRF52840 dongle board를 기반으로 zephyr BLE application을 만드는 과정을 소개하고자 한다.

To be continued ...

6. References
<zephyr>
[1] https://docs.zephyrproject.org/latest/
[2] Zephyr Project: RTOS Startup and Initialization Flow, David Leach, NXP Semiconductors ELC 2021 *****
[3] Zephyr RTOS Embedded C Programming Using Embedded RTOS POSIX AP, Apress, Andrew Eliasz

<adxl345 sensor>
[17] https://www.analog.com/en/products/adxl345.html#documentation
[18] https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf

[19] And, Google~

Slowboot