easy blog

ftrace script

easy16 — Sun, 28 Dec 2025 18:39:39 +0900

#!/bin/bash


echo 0 > /sys/kernel/debug/tracing/tracing_on
echo "ftrace off"
sleep 3
cp /sys/kernel/debug/tracing/trace .
mv trace ftrace_log

setter

#!/bin/bash


echo 0 > /sys/kernel/debug/tracing/tracing_on
sleep 1

echo 0 > /sys/kernel/debug/tracing/events/enable
sleep 1
echo "events disabled"

#echo secondary_start_kernel > /sys/kernel/debug/tracing/set_ftrace_filter
#sleep 1
#echo "set_ftrace_filter init"


echo function > /sys/kernel/debug/tracing/current_tracer
sleep 1
echo "function tracer enabled"

#echo rpi_get_interrupt_info > /sys/kernel/debug/tracing/set_ftrace_filter
#echo show_interrupts > /sys/kernel/debug/tracing/set_ftrace_filter
echo zoneinfo_show > /sys/kernel/debug/tracing/set_ftrace_filter
sleep 1
echo "set_ftrace_filter enabled"

#echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable
#echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_exit/enable

echo "event enabled"

echo 1 > /sys/kernel/debug/tracing/options/func_stack_trace
echo "function stack trace enabled"

echo 1 > /sys/kernel/debug/tracing/options/func_stack_trace
echo 1 > /sys/kernel/debug/tracing/options/sym-offset
echo "function stack trace enabled"


echo 1 > /sys/kernel/debug/tracing/tracing_on
echo "tracing on"

getter

/proc/meminfo와 zoneinfo의 관계

easy16 — Sun, 28 Dec 2025 16:53:57 +0900

/proc/meminfo의 값들을 계산할 때도 zoneinfo에서 사용되는 page 정보들을 이용해 계산되는가

네, 정확히 맞습니다!

/proc/meminfo의 값들은 /proc/zoneinfo의 페이지 정보들을 집계해서 계산됩니다.

/proc/meminfo의 주요 항목 계산

// linux/mm/page_alloc.c에서
si_meminfo() 함수가 zoneinfo를 읽어서 meminfo 계산

MemTotal = Σ(모든 zone의 managed)
MemFree = Σ(모든 zone의 free)
MemAvailable = MemFree + 회수 가능한 페이지들
MemUsed = MemTotal - MemFree
```

## 당신의 RPi4 데이터로 검증
```
/proc/zoneinfo에서:
Node 0, DMA:      managed = 220735,  free = 215866
Node 0, DMA32:    managed = 253815,  free = 133994
Node 1, DMA32:    managed = 497449,  free = 380141
                  ──────────────────  ──────────────
                  합계 = 971999       합계 = 730001

↓ 이를 /proc/meminfo로 변환 ↓

MemTotal = 971999 × 4 = 3,887,996 KB
MemFree = 730001 × 4 = 2,920,004 KB

/proc/meminfo의 다른 항목들도 zoneinfo 기반

bash

MemTotal       = Σ managed
MemFree        = Σ free
MemAvailable   = MemFree + (회수 가능한 파일 캐시)
Buffers        = 버퍼 캐시 (zoneinfo의 nr_file_pages 관련)
Cached         = 파일 캐시 (zoneinfo의 nr_active_file + nr_inactive_file)
Active         = Σ nr_active_anon + nr_active_file
Inactive       = Σ nr_inactive_anon + nr_inactive_file
AnonPages      = Σ nr_anon_pages
Slab           = Σ (nr_slab_reclaimable + nr_slab_unreclaimable)

커널 소스코드

// mm/page_alloc.c
void si_meminfo(struct sysinfo *val)
{
    unsigned long pages = 0;
    
    // 모든 zone 순회
    for_each_zone(zone) {
        pages += zone->managed_pages;      // MemTotal 계산
    }
    val->totalram = pages;
    
    // MemFree 계산
    val->freeram = global_node_page_state(NR_FREE_PAGES);
    
    // 기타 항목들...
}

실제 확인 방법

bash

# zoneinfo의 managed 합계
awk '/managed/{sum+=$2} END {print "MemTotal = " sum*4 " KB"}' /proc/zoneinfo

# zoneinfo의 free 합계
awk '/pages free/{sum+=$3} END {print "MemFree = " sum*4 " KB"}' /proc/zoneinfo

# /proc/meminfo 값과 비교
grep "MemTotal\|MemFree" /proc/meminfo
```

## 더 상세한 대응관계
```
/proc/meminfo 항목          zoneinfo 출처
─────────────────────────────────────────────
MemTotal                    Σ managed
MemFree                     Σ free
MemAvailable                MemFree + 회수 가능
Buffers                     (버퍼 캐시)
Cached                      Σ nr_file_pages
Active(anon)                Σ nr_active_anon
Inactive(anon)              Σ nr_inactive_anon
Active(file)                Σ nr_active_file
Inactive(file)              Σ nr_inactive_file
AnonPages                   Σ nr_anon_pages
Slab                        Σ nr_slab_reclaimable + 
                              nr_slab_unreclaimable
KernelStack                 Σ nr_kernel_stack
PageTables                  Σ nr_page_table_pages
```

## 계층 관계
```
/proc/zoneinfo (세부 정보)
        ↑
        │ (커널이 집계)
        ↓
/proc/meminfo (통합 정보)
        ↑
        │ (사용자가 조회)
        ↓
free, top 등의 도구

결론:

✅ /proc/meminfo는 /proc/zoneinfo 정보를 실시간으로 집계해서 만들어짐
✅ zoneinfo의 managed/free 합계 × 4K = meminfo의 MemTotal/MemFree
✅ 둘 다 같은 커널 메모리 관리 데이터 구조에서 나옴

/proc/zoneinfo 해석 방법

easy16 — Sun, 28 Dec 2025 16:25:06 +0900

/proc/zoneinfo 해석 가이드

핵심 항목만 보기

복잡해 보이지만, 실제로 중요한 항목은 몇 개입니다.

1단계: 노드(Node)와 존(Zone) 파악

Node 0, zone DMA      ← NUMA Node 0의 DMA 영역
Node 0, zone DMA32    ← NUMA Node 0의 DMA32 영역
Node 1, zone DMA32    ← NUMA Node 1의 DMA32 영역

당신의 경우: 2개 노드, 각각 DMA + DMA32 영역만 사용

2단계: 각 Zone의 메모리 상태

RPi4 기준으로 중요한 항목:

Node 0, zone DMA
  pages free     215866        ← 사용 가능한 페이지 수
        managed  220735        ← 관리 중인 전체 페이지 수
        cma      131072        ← CMA 영역 (카메라/GPU용)
  nr_free_cma  126266          ← 사용 가능한 CMA 페이지

간단한 계산:

215866 pages × 4KB = 약 843MB 자유 메모리 (DMA 존)
126266 CMA pages × 4KB = 약 492MB (GPU/카메라용 예약)

3단계: 간단한 해석 패턴

bash

# 이 명령으로 깔끔하게 보기
grep -E "zone|free|managed|cma" /proc/zoneinfo
```

**출력 예:**
```
Node 0, zone      DMA
  pages free     215866        # ✓ 자유 메모리
        managed  220735        # 관리 중
        cma      131072        # GPU 예약
  nr_free_cma  126266          # ✓ 사용 가능한 CMA

Node 0, zone    DMA32
  pages free     133994        # ✓ 자유 메모리
        managed  253815        # 관리 중
```

## RPi4 당신의 상황 분석
```
Node 0 (CPU 0,1 담당):
  DMA:   215,866 pages free (약 843MB) - GPU 공유
  DMA32: 133,994 pages free (약 523MB)
  
Node 1 (CPU 2,3 담당):
  DMA32: 380,141 pages free (약 1.4GB)

전체: 약 2.7GB 자유 메모리
```

## 추가 유용한 해석

**per-cpu pageset (CPU별 캐시):**
```
pagesets
  cpu: 0
        count: 62           ← CPU 0의 로컬 캐시 페이지 수
        high:  290         ← 상한선 (초과하면 buddy로 반환)
        batch: 63          ← 배치 크기
  cpu: 1
        count: 0           ← CPU 1은 로컬 캐시 비어있음
```

**최소/최대 임계값:**
```
min:  930    ← 이 이하면 메모리 부족
low:  1162   ← kswapd 깨우는 수준
high: 1394   ← 여유 있는 수준

한 줄로 상태 확인

bash

# 전체 자유 메모리 계산
awk '/pages free/{sum+=$3} END {print sum*4 "KB =" sum/256 "MB"}' /proc/zoneinfo
```

**당신의 시스템:**
```
약 750,000 pages × 4KB = 약 2.9GB 자유 메모리

스크립트로 간단하게 보기

bash

#!/bin/bash
echo "=== Zone 메모리 상태 ==="
awk '/^Node/ {node=$2} /^  zone/ {zone=$2} /pages free/ {free=$3} /managed/ {managed=$2} /nr_free_cma/ {cma=$2} /^$/ {if(node) printf "Node %s, %s: Free=%dMB (CMA=%dMB), Total=%dMB\n", node, zone, free*4/256, cma*4/256, managed*4/256}' /proc/zoneinfo

가장 간단한 방법

bash

# 1. 전체 자유 메모리만 보기
free -h

# 2. Zone별 상세는 이 부분만 보기
grep -A3 "^Node" /proc/zoneinfo | grep -E "free|managed"

결론:

free = 사용 가능한 페이지 수
managed = 관리 중인 전체 페이지 수
cma = GPU/카메라용 예약 영역
나머지는 대부분 무시해도 됨

nr_은 무엇의 약자야? , managed는 어떤 의미인지 모르겠어 사용 중인거야 사용 가능한거야

오후 4:27

nr_과 managed의 의미

nr_ = "number of"의 약자

nr_free_pages   = number of free pages (자유 페이지의 수)
nr_dirty        = number of dirty pages (더티 페이지의 수)
nr_slab_reclaimable = number of slab reclaimable (회수 가능한 slab의 수)
```

**정리:**
- `nr_` = **개수/숫자**를 나타내는 접두사
- 항상 "몇 개인가"를 의미

---

## managed = 커널이 관리하는 페이지
```
물리 메모리
├─ 예약된 영역 (BIOS, 부트로더 등) - 커널이 건드리지 않음
├─ managed ← 커널이 관리할 수 있는 영역
│   ├─ free (사용 가능)
│   ├─ used (사용 중)
│   └─ ...
└─ (기타)
```

**쉽게 말하면:**
- **managed** = 커널이 할당/관리하는 페이지 풀
- **free** = managed 중에서 **지금 비어있는** 것

---

## 구체적 예시
```
Node 0, zone DMA
  pages free     215866    ← 현재 비어있는 페이지
        managed  220735    ← 커널이 관리할 수 있는 전체 페이지
        
사용 중인 페이지 = managed - free
               = 220735 - 215866
               = 4869 pages (약 19MB 사용 중)

다른 항목들과의 관계

struct zone {
    // 페이지 상태 분류
    managed          // 커널이 관리 가능한 전체 페이지
    ├─ free          // 사용 가능한 페이지 (할당 대기 중)
    └─ used (암묵적)
        ├─ nr_active_anon        // 활성 익명 페이지 (메모리)
        ├─ nr_inactive_anon      // 비활성 익명 페이지
        ├─ nr_active_file        // 활성 파일 캐시
        ├─ nr_inactive_file      // 비활성 파일 캐시
        ├─ nr_kernel_stack       // 커널 스택
        ├─ nr_page_table_pages   // 페이지 테이블
        └─ ... (기타 사용 중인 페이지)
};
```

## 당신의 RPi4 데이터로 분석
```
Node 0, zone DMA
  managed: 220735 pages (전체 관리 페이지)
  free:    215866 pages (현재 사용 가능)
  
  사용 중: 220735 - 215866 = 4869 pages
         = 약 19MB 사용 중
         
  내역:
    nr_active_anon:     0      (익명 페이지)
    nr_active_file:     0      (파일 캐시)
    nr_kernel_stack:    ?      (커널 스택)
    ... (합쳐서 4869)

Node 0, zone DMA32
  managed: 253815 pages (전체 관리 페이지)
  free:    133994 pages (현재 사용 가능)
  
  사용 중: 253815 - 133994 = 119821 pages
         = 약 467MB 사용 중
         
  내역:
    nr_zone_active_anon:  22471  (활성 메모리)
    nr_zone_inactive_anon: 0
    nr_zone_active_file:  32489  (파일 캐시)
    nr_zone_inactive_file: 45782
    ... (합쳐서 119821)
```

## 메모리 상태 정리

| 항목 | 의미 | 상태 |
|------|------|------|
| **managed** | 커널이 관리 가능 | 포함된 범위 정의 |
| **free** | 현재 비어있음 | ✓ 할당 가능 |
| **used** (managed - free) | 현재 사용 중 | 이미 할당됨 |
| **nr_active_anon** | 활성 메모리 페이지 | used에 포함 |
| **nr_active_file** | 활성 캐시 페이지 | used에 포함 |

## 간단한 공식
```
managed = free + used
        = free + (nr_active_anon + nr_inactive_anon + 
                  nr_active_file + nr_inactive_file + 
                  nr_kernel_stack + ...)

결론:

nr_ = "개수" (number of)
managed = 커널이 관리하는 페이지 풀의 크기
free = managed 중 현재 비어있는 것
used = managed 중 현재 사용 중인 것

present와 managed 차이

오후 4:29

present vs managed 차이

핵심

present  = 물리적으로 실제 존재하는 페이지
managed  = 커널이 실제로 관리/할당할 수 있는 페이지

구체적 차이

physical memory (물리 메모리)
│
├─ present: 242688 pages (실제 존재)
│  │
│  ├─ reserved (예약됨 - 커널이 건드리지 않음)
│  │  ├─ BIOS 영역
│  │  ├─ 부트로더
│  │  └─ 펌웨어 (RPi4의 GPU 펌웨어)
│  │
│  └─ manageable (관리 가능)
│     └─ managed: 220735 pages ← 커널이 할당/관리
│        ├─ free: 215866 (사용 가능)
│        └─ used: 4869 (사용 중)

당신의 RPi4 데이터로 보기

Node 0, zone DMA
  present  242688    ← 실제 존재하는 물리 페이지
  managed  220735    ← 커널이 관리하는 페이지
  
  예약됨 = present - managed
        = 242688 - 220735
        = 21953 pages (약 85MB)
        
이 85MB는 GPU, 부트로더, BIOS 등이 사용

Node 0, zone DMA32
  present  262144    ← 실제 존재
  managed  253815    ← 커널이 관리
  
  예약됨 = 262144 - 253815
        = 8329 pages (약 32MB)

왜 managed < present일까?

RPi4 특성:

present = 242688 pages
  ├─ GPU 펌웨어 영역 (RPi4는 ARM CPU와 GPU 공유)
  ├─ 부트로더
  ├─ 디바이스 트리 (device tree)
  ├─ BIOS/UEFI 영역
  └─ managed: 220735 pages만 Linux가 관리

일반 PC vs RPi4:

일반 PC:
  present ≈ managed (대부분 예약 영역 없음)
  
RPi4:
  present > managed (GPU가 메모리 독점, 공유 메모리 존재)
  present - managed = 약 10% (GPU 펌웨어용)

메모리 계층 구조 (정확한 버전)

Physical Memory (물리적으로 존재)
│
├─ Node 0, zone DMA
│  │
│  ├─ present: 242688 pages
│  │  │
│  │  ├─ reserved (커널이 관리 안 함)
│  │  │  └─ 21953 pages (GPU, 펌웨어 등)
│  │  │
│  │  └─ managed: 220735 pages ← 커널이 관리
│  │     ├─ free: 215866 pages (할당 가능)
│  │     └─ used: 4869 pages (사용 중)
│  │        ├─ nr_kernel_stack
│  │        ├─ nr_page_table_pages
│  │        └─ ...
│  │
│  └─ cma: 131072 pages (GPU용 연속 메모리, managed에 포함)
│     ├─ nr_free_cma: 126266 (사용 가능)
│     └─ used_cma: ~5000
│
└─ Node 0, zone DMA32
   ├─ present: 262144
   └─ managed: 253815
      ├─ free: 133994
      └─ used: 119821

spanned vs present vs managed

Node 0, zone DMA
  spanned: 262144   ← 이 zone이 담당하는 주소 범위의 페이지 수
  present: 242688   ← 그 중 실제 존재하는 페이지 수
  managed: 220735   ← 그 중 커널이 관리하는 페이지 수
  
spanned > present (어떤 주소는 비어있을 수 있음)
present > managed (일부는 예약됨)

공식

spanned   = zone의 주소 범위로 계산한 페이지 수
present   = spanned 중 실제 물리 메모리가 있는 페이지
managed   = present 중 커널이 할당 가능한 페이지
free      = managed 중 현재 비어있는 페이지

따라서:
spanned ≥ present ≥ managed ≥ free

요약표

항목의미예시

spanned	이론적 범위	262144 pages
present	실제 존재	242688 pages
managed	커널 관리	220735 pages
free	현재 사용 가능	215866 pages

결론:

present = 물리적으로 "실제 있는" 페이지
managed = 물리적으로 있으면서 "커널이 관리하는" 페이지
RPi4에서 present - managed ≈ GPU 펌웨어용 메모리

zone, free_area, list_head[MIGRATE_TYPES] 관련

easy16 — Sun, 28 Dec 2025 16:20:14 +0900

Q.free_area는 4K의 승수별로 존재, list_head는 type 별 리스트를 가진다고 이해하면 되나

정확합니다! 당신의 이해가 맞습니다.

정리

free_area[order]의 구조:

free_area[0]  (2^0 = 1 page = 4KB)
├─ free_list[MIGRATE_UNMOVABLE]  → [page] → [page] → ...
├─ free_list[MIGRATE_MOVABLE]    → [page] → [page] → ...
├─ free_list[MIGRATE_RECLAIMABLE]→ [page] → [page] → ...
├─ free_list[MIGRATE_HIGHATOMIC] → [page] → ...
└─ free_list[MIGRATE_CMA]        → [page] → ...

free_area[1]  (2^1 = 2 pages = 8KB)
├─ free_list[MIGRATE_UNMOVABLE]  → [page] → [page] → ...
├─ free_list[MIGRATE_MOVABLE]    → [page] → [page] → ...
├─ free_list[MIGRATE_RECLAIMABLE]→ ...
├─ free_list[MIGRATE_HIGHATOMIC] → ...
└─ free_list[MIGRATE_CMA]        → ...

free_area[2]  (2^2 = 4 pages = 16KB)
├─ free_list[...]
└─ ...

...

free_area[10] (2^10 = 1024 pages = 4MB)
├─ free_list[...]
└─ ...

코드로 보면

struct zone {
    struct free_area free_area[MAX_ORDER];  // MAX_ORDER = 11
};

struct free_area {
    struct list_head free_list[MIGRATE_TYPES];  // MIGRATE_TYPES = 5
    unsigned long nr_free;
};

예시: 8KB 메모리 블록 찾기

// 8KB (2 pages) 크기의 MOVABLE 타입 메모리를 찾고 싶다면
struct list_head *target = &zone->free_area[1].free_list[MIGRATE_MOVABLE];
//                                          ↑                        ↑
//                                     order=1 (8KB)        type별 리스트
//                                    (2^1 page blocks)

할당/해제 관점

// 8KB 할당 요청이 오면
// → order=1, migratetype=MIGRATE_MOVABLE인 경우
// → zone->free_area[1].free_list[MIGRATE_MOVABLE]에서 페이지 블록 추출

// 8KB 메모리 해제
// → order=1, migratetype=MIGRATE_MOVABLE
// → zone->free_area[1].free_list[MIGRATE_MOVABLE]에 페이지 블록 추가
```

## 마이그레이션 타입 분리의 이점
```
같은 크기(order)여도 타입별로 분리:

free_area[1].free_list[MIGRATE_MOVABLE]    → 이동 가능한 8KB 블록들
free_area[1].free_list[MIGRATE_UNMOVABLE] → 이동 불가능한 8KB 블록들

→ 커널이 8KB 메모리를 할당할 때 UNMOVABLE 영역에서만 찾기
→ MOVABLE 영역을 보존 (메모리 압축/조각화 방지)

당신의 이해가 정확합니다!

✅ 크기: 4KB의 승수별로 존재 (2^0, 2^1, ... 2^10)
✅ 리스트: 각 크기별로 타입에 따른 5개의 리스트 보유

Q. 여기서 MIGRATE_TYPES는 zone의 종류와는다른거야?

네, 완전히 다른 개념입니다!

구분

MIGRATE_TYPES = 페이지의 이동 가능성 속성

#define MIGRATE_UNMOVABLE       0  // 커널이 사용, 이동 불가
#define MIGRATE_MOVABLE         1  // 사용자 프로세스, 이동 가능
#define MIGRATE_RECLAIMABLE     2  // 캐시, 회수 가능
#define MIGRATE_HIGHATOMIC      3  // 원자적 할당 예약
#define MIGRATE_CMA             4  // Contiguous Memory Allocator

Zone = 메모리의 물리적 위치 기준

enum zone_type {
    ZONE_DMA,        // 0-16MB (DMA 가능)
    ZONE_DMA32,      // 0-4GB (32bit DMA)
    ZONE_NORMAL,     // 일반 메모리
    ZONE_HIGHMEM,    // 고위 메모리 (32bit)
    ZONE_MOVABLE,    // 이동 가능 영역
    // ...
};

struct zone {
    struct free_area free_area[MAX_ORDER];
    // ...
};
```

## 계층 구조
```
Node (NUMA)
  ↓
Zone (DMA, NORMAL, HIGHMEM, ...)
  ↓
free_area[0..10] (크기별: 4KB, 8KB, 16KB, ..., 4MB)
  ↓
free_list[MIGRATE_TYPES] (타입별: UNMOVABLE, MOVABLE, ...)
  ↓
[페이지] → [페이지] → [페이지] → ...

구체적 예시

// ZONE_NORMAL에서 8KB 메모리 할당

struct zone *zone = &NODE_DATA(0)->node_zones[ZONE_NORMAL];
//                                           ↑
//                                     물리적 위치 (Zone)

struct free_area *area = &zone->free_area[1];
//                                        ↑
//                                    크기 (8KB = 2^1)

struct list_head *list = &area->free_list[MIGRATE_MOVABLE];
//                                         ↑
//                                 이동 가능성 (Type)

// 실제 페이지 추출
page = list_first_entry_or_null(list, struct page, lru);
```

## 메모리 레이아웃
```
ZONE_DMA (0-16MB)
├─ free_area[0]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  ├─ free_list[MIGRATE_MOVABLE]
│  └─ ...
├─ free_area[1]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  └─ ...
└─ ...

ZONE_NORMAL (16MB-4GB)
├─ free_area[0]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  ├─ free_list[MIGRATE_MOVABLE]
│  └─ ...
├─ free_area[1]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  └─ ...
└─ ...

ZONE_HIGHMEM (4GB 이상)
├─ free_area[0]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  └─ ...
└─ ...

커널 코드에서

// mm/page_alloc.c
static struct page *
get_page_from_freelist(gfp_t gfp_mask, unsigned int order,
                       int alloc_flags, const struct alloc_context *ac)
{
    struct zoneref *z;
    struct zone *zone;
    struct page *page = NULL;
    
    // 1. Zone 순회 (DMA → NORMAL → ...)
    for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
                                    ac->highest_zoneidx, ac->nodemask) {
        // 2. free_area[order] 선택
        // 3. free_list[migratetype] 선택
        // 4. 페이지 추출
    }
    
    return page;
}

정리

항목기준종류

Zone	물리적 위치	DMA, NORMAL, HIGHMEM, ...
free_area[order]	메모리 크기	4KB, 8KB, 16KB, ..., 4MB
MIGRATE_TYPES	페이지 속성/이동성	UNMOVABLE, MOVABLE, ...

MIGRATE_TYPES는 Zone과 무관하게, 각 Zone의 모든 free_area에서 타입별로 페이지를 분류하는 것입니다!

raspberry pi4 kernel dump test

easy16 — Sun, 28 Dec 2025 11:49:26 +0900

objdump -x vmlinux | grep show_interrupts -A 10

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0xffffffc080000000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          35974344 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         4
  Size of section headers:           64 (bytes)
  Number of section headers:         38
  Section header string table index: 37

readelf -h vmlinux

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0xffffffc080000000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          35974344 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         4
  Size of section headers:           64 (bytes)
  Number of section headers:         38
  Section header string table index: 37

#특정 심볼의 주소 찾기
vi System.map
echo ffffffc0801319a8 //show_interrupts의 심볼 및 start/end address 검색

#특정함수의 어셈블리 보기
aarch64-linux-gnu-objdump --start-address=0xffffffc0801319a8 --stop-address=0xffffffc080131d38 -d vmlinux

vmlinux:     file format elf64-littleaarch64


Disassembly of section .text:

ffffffc0801319a8 <show_interrupts>:
ffffffc0801319a8:       d503201f        nop
ffffffc0801319ac:       d503201f        nop
ffffffc0801319b0:       d503233f        paciasp
ffffffc0801319b4:       a9bb7bfd        stp     x29, x30, [sp, #-80]!
ffffffc0801319b8:       9000bba2        adrp    x2, ffffffc0818a5000 <_printk_rb_static_descs+0x17b10>
ffffffc0801319bc:       910003fd        mov     x29, sp
ffffffc0801319c0:       a9025bf5        stp     x21, x22, [sp, #32]
ffffffc0801319c4:       b9492844        ldr     w4, [x2, #2344]
ffffffc0801319c8:       f9400035        ldr     x21, [x1]
ffffffc0801319cc:       6b15009f        cmp     w4, w21
ffffffc0801319d0:       5400156b        b.lt    ffffffc080131c7c <show_interrupts+0x2d4>  // b.tstop
ffffffc0801319d4:       540015e0        b.eq    ffffffc080131c90 <show_interrupts+0x2e8>  // b.none
ffffffc0801319d8:       a90153f3        stp     x19, x20, [sp, #16]
ffffffc0801319dc:       aa0003f3        mov     x19, x0
ffffffc0801319e0:       35000615        cbnz    w21, ffffffc080131aa0 <show_interrupts+0xf8>
ffffffc0801319e4:       a90363f7        stp     x23, x24, [sp, #48]
ffffffc0801319e8:       52800082        mov     w2, #0x4                        // #4
ffffffc0801319ec:       52807d01        mov     w1, #0x3e8                      // #1000
ffffffc0801319f0:       710f9c9f        cmp     w4, #0x3e7
ffffffc0801319f4:       5400164d        b.le    ffffffc080131cbc <show_interrupts+0x314>
ffffffc0801319f8:       0b010821        add     w1, w1, w1, lsl #2
ffffffc0801319fc:       2a0203e3        mov     w3, w2

raspberry pi 4 커널 빌드 및 교체 시 주의 사항

easy16 — Fri, 26 Dec 2025 22:12:45 +0900

config 생성 및 커널 이미지 빌드는 아래 스크립트의 명령어 참조

아래와 같이 OUTPUT를 O 옵션으로 지정하면, 커널 코드 내 변경 없이 깔끔하게 빌드할 수 있는 장점이 있음

윈도우 wsl에서 cross compile 환경으로 빌드를 하다보니, 가이드 대로 하는게 불가능함.

편의를 위해 먼저 rpi4의 root 패스워드를 지정하고 dtb* 및 Image 만 복사하면 될 줄 알았는데, 커널 부팅이 안된다.

다행이도 윈도우에서 kernel8.img를 간단히 복사 가능하므로 복구해주고..

결과물 중, vmlinux는 add2line이나 gdb 사용을 위한 이미지로 부팅이 불가

Image는 raw 형태로 대략 26M쯤 나간다.

이를 z 또는 lz 형태로 압축하면 8~9M로 줄고, 이게 기존 rpi4에서 배포된 이미지로 보임. (귀찮으니 확인은 생략)

커널 버전이 달라서 커널 모듈이 모두 재컴파일 필요함. (처음부터 버전을 맞춰서 구할 수 있으면 좋았을텐데)

매우 귀찮지만, modules_install을 wsl내 임의의 경로에서 진행

타겟에서 lsblk을 실행하면, boot는 mmcblock1 root는 2에 있다는게 확인 가능하므로 가이드대로 적당히 마운트 후 복사하면 됨.

이후 tar로 묶어 타겟의 /lib/modules 경로에서 풀고 재부팅하면, 동작이 가능하다.

장난감 완성~

#!/bin/bash
#
#
#KERNEL_TOP_PATH="$( cd "$(dirname "$0")" ; pwd -P )"
KERNEL_TOP_PATH="$( cd "$(dirname "$0")" ; pwd -P )"
#KERNEL_TOP_PATH="/root/workspace/project/rpi4/linux"
OUTPUT="$KERNEL_TOP_PATH/out"
BUILD_LOG=$KERNEL_TOP_PATH/rpi_build_log.txt
echo "$OUTPUT"

cd linux
#if build error happens
#make ARCH=arm64 mrproper -j10
KERNEL=kernel8
make O=$OUTPUT ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) bcm2711_defconfig
#make O=$OUTPUT ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) Image modules dtbs 2>&1 | tee $BUILD_LOG
#tar the output dir in /lib/modules/xxx and scp to target
make O=$OUTPUT ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) INSTALL_MOD_PATH=../out/mnt/root modules_install

커널 다운로드 및 빌드 가이드는 다음 링크 참조

https://www.raspberrypi.com/documentation/computers/linux_kernel.html

The Linux kernel - Raspberry Pi Documentation

The official documentation for Raspberry Pi computers and microcontrollers

www.raspberrypi.com

BFT 의견

easy16 — Wed, 1 Oct 2025 17:31:46 +0900

Playstore link

https://play.google.com/store/apps/details?id=com.baby.feeding.calculator

WEB link

https://play.google.com/apps/internaltest/4701564922685857537

https://play.google.com/apps/testing/com.baby.feeding.calculator

GoogleGroups

https://groups.google.com/g/bftbetatester1/

https://play.google.com/store/apps/details?id=com.baby.feeding.calculator

https://play.google.com/apps/testing/com.baby.feeding.calculator

문의사항은 댓글로 달아주세요.

Baby Feed Timer 개인정보 처리 방침

easy16 — Sun, 28 Sep 2025 15:55:24 +0900

개인정보처리방침

아기 수유 타이머(이하 "앱")는 사용자의 개인정보를 중요하게 생각하며, 개인정보보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률 등 관련 법령을 준수하고 있습니다.

1. 수집하는 개인정보의 항목

1.1 직접 수집 정보

본 앱은 다음과 같은 정보를 수집합니다:

수집 항목수집 목적보관 기간

아기 이름	개인화된 수유 관리 서비스 제공	앱 삭제 시까지
아기 출생일	연령별 맞춤 수유량 계산	앱 삭제 시까지
아기 체중	체중별 적정 수유량 계산	앱 삭제 시까지
수유 기록 (시간, 양)	수유 패턴 분석 및 다음 수유 시간 예측	앱 삭제 시까지
언어 설정	다국어 서비스 제공	앱 삭제 시까지

1.2 자동 수집 정보

광고 식별자 (AdMob): 맞춤형 광고 제공을 위해 Google AdMob에서 수집
앱 사용 패턴: 서비스 개선을 위한 익명화된 사용 통계
디바이스 정보: 앱 최적화 및 오류 분석

중요: 모든 개인정보는 사용자의 기기에만 저장되며, 외부 서버로 전송되지 않습니다.

2. 개인정보 처리 목적

서비스 제공: 아기의 수유량 계산, 수유 기록 관리, 수유 시간 알림
서비스 개선: 사용자 경험 향상을 위한 기능 개발 및 최적화
광고 서비스: Google AdMob을 통한 관련성 높은 광고 제공
알림 서비스: 수유 시간 알림 및 중요 공지사항 전달
다국어 지원: 사용자 언어 설정에 따른 맞춤형 인터페이스 제공

3. 개인정보 보유 및 이용기간

앱 내 저장 데이터: 앱 삭제 시까지
광고 관련 데이터: Google AdMob 정책에 따름 (일반적으로 13개월)
크래시 로그: 앱 안정성 향상을 위해 최대 1년간 보관 후 자동 삭제

4. 개인정보 제3자 제공

본 앱은 사용자의 개인정보를 제3자에게 제공하지 않습니다. 단, 다음의 경우는 예외입니다:

4.1 Google AdMob

제공받는 자제공 목적제공 항목보관 기간

Google LLC

맞춤형 광고 제공

광고 식별자, 기기 정보, 앱 사용 통계

Google 광고 정책에 따름

Google AdMob 관련 안내:
• Google의 개인정보처리방침: https://policies.google.com/privacy
• 광고 맞춤설정 관리: https://adssettings.google.com

5. 개인정보 처리 위탁

본 앱은 더 나은 서비스 제공을 위해 다음과 같이 개인정보 처리를 위탁하고 있습니다:

수탁업체위탁업무연락처

Google LLC

광고 서비스 제공

https://support.google.com

6. 사용자의 권리와 행사 방법

사용자는 다음과 같은 권리를 가집니다:

열람권: 앱 내 설정에서 저장된 정보 확인 가능
정정·삭제권: 앱 내에서 직접 수정 및 삭제 가능
처리정지권: 앱 삭제를 통한 모든 데이터 처리 중단
광고 맞춤설정 해제: 기기 설정 또는 Google 광고 설정에서 변경

6.1 데이터 삭제 방법

개별 데이터: 앱 내 각 화면에서 삭제 버튼 이용
전체 데이터: 앱 삭제 또는 기기 설정에서 앱 데이터 삭제
광고 데이터: Google 광고 설정에서 광고 맞춤설정 해제

7. 개인정보 보호를 위한 기술적/관리적 대책

7.1 기술적 대책

로컬 데이터 암호화 저장
앱 코드 난독화를 통한 역공학 방지
최신 보안 프레임워크 적용
정기적인 보안 업데이트

7.2 관리적 대책

개인정보 접근 권한 최소화
개발자 보안 교육 실시
개인정보 처리 현황 정기 점검

8. 사용 권한 안내

권한사용 목적필수/선택

알림 (POST_NOTIFICATIONS)	수유 시간 알림 제공	선택
정확한 알람 (SCHEDULE_EXACT_ALARM)	정확한 수유 시간 알림	선택
인터넷 (INTERNET)	광고 서비스 제공	필수
네트워크 상태 (ACCESS_NETWORK_STATE)	광고 최적화	필수
화면 켜짐 유지 (WAKE_LOCK)	알림 기능 안정성	필수

9. 아동의 개인정보 보호

본 앱은 만 14세 미만 아동의 개인정보를 수집하지 않으며, 아기의 정보는 보호자가 입력하는 것으로 간주합니다. 만약 만 14세 미만 아동이 보호자 동의 없이 개인정보를 제공한 사실을 알게 될 경우, 즉시 해당 정보를 삭제하겠습니다.

10. 개인정보 처리방침 변경

본 개인정보처리방침은 법령이나 서비스의 변경사항을 반영하기 위한 목적 등으로 수정될 수 있습니다.

개인정보처리방침이 변경될 경우, 앱 업데이트를 통해 공지
중요한 변경사항의 경우 앱 내 팝업으로 별도 안내
변경된 개인정보처리방침은 게시된 날로부터 효력 발생

11. 개인정보 보호책임자 및 연락처

개인정보 보호책임자

성명: 이지현

이메일: dontbeshy8888@gmail.com

개인정보 관련 문의

개인정보 처리에 관한 문의사항이나 불만사항이 있으신 경우 위 연락처로 문의해 주시기 바랍니다.

신속하고 충분한 답변을 드릴 수 있도록 노력하겠습니다.

12. 권익침해 구제방법

개인정보 침해신고센터, 개인정보 분쟁조정위원회, 대검찰청 사이버범죄수사단, 경찰청 사이버안전국 등에 신고하거나 상담을 받으실 수 있습니다.

개인정보 침해신고센터: privacy.go.kr (전화: 국번없이 182)
개인정보 분쟁조정위원회: www.kopico.go.kr (전화: 1833-6972)
대검찰청 사이버범죄수사단: www.spo.go.kr (전화: 02-3480-3571)
경찰청 사이버안전국: cyberbureau.police.go.kr (전화: 국번없이 182)

특별 안내사항

본 앱은 오프라인 우선 방식으로 작동하며, 모든 핵심 데이터는 사용자 기기에만 저장됩니다.
인터넷 연결은 광고 표시 목적으로만 사용되며, 사용자 데이터 전송에는 사용되지 않습니다.
앱 삭제 시 모든 데이터가 완전히 삭제되며, 복구할 수 없습니다.
정기적인 보안 업데이트를 통해 사용자 데이터 보호에 최선을 다하고 있습니다.

시행일자: 2024년 [월] [일]

최종 수정일: 2024년 [월] [일]

android omx IL architecture

easy16 — Thu, 3 Nov 2022 22:03:47 +0900

https://source.android.com/docs/core/media

gst와 omx IL의 관계

easy16 — Thu, 3 Nov 2022 21:58:59 +0900

gst-openmax
openMAX IL
https://freedesktop.org/wiki/GstOpenMAX/

openMAX
https://www.khronos.org/api/openmax/il

gstreamer1

https://medium.com/may-i-lab/gstreamer-gstreamer-%EA%B8%B0%EC%B4%88-da5015f531fc

gstreamer2
https://gstreamer.freedesktop.org/features/index.html

GStreamer can bridge to other multimedia frameworks in order to reuse existing components (e.g. codecs) and use platform input/output mechanisms:

Linux/Unix: OpenMAX-IL (via gst-omx)
Windows: DirectShow
Mac OS X: QuickTime

GStreamer + OpenMAX-IL
https://www.khronos.org/files/openmax/whitepapers/OpenMAX_IL_with_GSstreamer.pdf