Github Page

레이블이 Yocto인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Yocto인 게시물을 표시합니다. 모든 게시물 표시

10/17/2025

CXL 의 이해 와 구조

1. CXL(Compute Express Link) 의 이해 

CXL (Compute Express Link) 에 대해 급하게 알아야 할 듯하여,관련 자료들을 수집하고 학습. 

  • CXL(Compute Express Link) 란?
PCIe 기반으로 사용되어지는, 고속 DMA Controller 비슷할 것 같다. 
즉 CPU 입장에서 생각하면, 각 Cache 에 연결된 AMBA(AHB,APB,AXI) 와 DMA를 이용하여 각 Memory 고속으로 전송하는 Bus Switch Interface가 맞을 듯 하다 

  • UCIe
CXL 기반으로 출발한 것 같으며, 현재 Chiplet이라는 ,즉 실리콘 즉 반도체에서 이를 다 연결하려고 하는 Interface가 맞을 것 같다.

  • PCIe
PCI에서 발전된 Bus로 PCI/HPI는 직접 Driver를 개발했지만, PCIe 직접 개발해보지 못해 이 부분은 나중에 별도로 정리하도록 한다. 
요즘은 솔직히 Kernel Platform화가 잘 되어있어, 개발보다는 주로 설정하고 변경하는 것이라 이 부분은 별도로 기회가 있으면 다시 정리하도록 하겠다. 

  • CXL 의 개인적 생각 과 결론 
종합적으로 보면, CXL는 PCIe Interface 이용하지만, CPU 의 내부에서 비교하자면, AMBA(PCIe) 역할과 DMA Contorller 와 Memory Controller 가능 일 것이다. 
그러니, CPU 밖에서, 다양한 CPU들 과 연결하는 것도 쉽게 가능 하리라고 본다. 
더 나아가 왜 UCIe가 실리콘, 즉 반도체  위에서 한다는 이유도 대충 이해가 가는 듯하다. 


1.1 CXL 구조 와 CXL Type 

  • CXL 구조 와 Type 의 이해 
CXL에 대해 쉽게 설명이 되어 있어 , CXL 기본 구조 와 Type 1/2/3 쉽게 이해 
CXL 2.0 이 후 Type1/2/3 기반으로 연결 확장 가능하며, 이를 다양하게 더 확장이 가능 설명  

  • CXL 의 Spec 과 이해 
1.6 Flex Bus Layering Overview : Flex Bus 의 이해 
2.0 Compute Express Link System Architecture : CXL의 Type1/2/3 의 이해 
PDF의 좌측 Index 기반으로 각 살펴보면,  쉽게 감이 잡히는 듯하다 
관련 그림들은 혹시 문제가 될 듯해서 가져오지 않음 

Compute Express Link Consortium
  1. CXL 최신 Spec 신청가능하며 왠지 무료는 아닐듯?
  2. 일단 Spec 1.0으로만 만족 
 

  • CXL Device Type 1/2/3 구조 와 역할 
CXL Type 포함 프로토콜 주요 역할 예시 디바이스 특징
Type 1 CXL.io + CXL.cache 가속기(Accelerator) – 호스트 메모리를 캐시 형태로 접근 Smart NIC, FPGA Accelerator, AI Inference Engine 자체 메모리는 거의 없고, Host DRAM을 Cache Access 함
Type 2 CXL.io + CXL.cache + CXL.mem 고성능 가속기 – Host 메모리 접근 + 자체 메모리 공유 가능 GPU, FPGA with onboard HBM, AI Chip 호스트와 디바이스가 서로의 메모리에 Coherent Access
Type 3 CXL.io + CXL.mem 메모리 익스팬더(Memory Expander) – Host에 추가 메모리 제공 CXL.DIMM, CXL Memory Card, Persistent Memory CPU가 Device 메모리를 Load/Store 식으로 사용


  • CXL Controller 관점의 비교  
각 Host 와 CXL Device(CXL Controller) 관점에서 비교를 해보자. 
Cache 에 따라 성능이 변경되므로, 
Coherency Directory 즉 Cache 의 일관성을 어디까지 해야 하는 지이며, 알고리즘은 어떤 것을 쓰는지 또, 범위는 어디까지 하는 지가 중요하다(이 부분 다시 밑에) 

구성 요소 Type 1 Type 2 Type 3
CXL.cache ✔ ✔ ✘
CXL.mem ✘ ✔ ✔
CXL.cache ✔ ✔ ✘
Coherency Directory (Host side only) (Host + Device side) (Host side only)
Local DRAM Access ✘ ✔ ✘
목적 Compute 가속 Compute + 메모리공유 Pure Memory 확장

  • CXL Device Type1/2/3 확장 (결합)
CXL 2.0 이상부터는 이 Type 1/2/3 디바이스를 스위치와 Fabric구조에서 논리적 결합(Logical Device) 으로 묶을 수도 있다고 한다. 
증권사 자료이지만, 이해 하기가 자료 좋음 

  • CXL Fabric 간단 정리 
지능형 연결망이라고 하는데, 각 기능들을 Thread 즉 실로 보고, 이를 엮어서 각 기능들의 총체적인 기능을 말한다고 한다. 
즉 CXL Fabric 구조는 여러 외부 CPU들 과 다양한 Peripherial 들 연결 확장까지도 생각을 해볼 수 있는 것이다. 



1.2 CXL Swtich 구조 

다양한 PCIe Channel 들을 처리하기 때문에 Arbiter/Mux 는 역할이 중요할 것 같으며, 
즉, DMA Controller 역할이 비슷할 거라고 생각되어진다.
상위 Spec1.0 보면 다양한 기능들이 들어가면서, 다양한 기능들을 처리하려면, 단순한 DMA Controller가 아닌 복합적인 DMA Controller 동작할 거 같다. 

CXL Switch 역시 여러 CXL Device Type 1/2/3 조합으로 각 CXL switch 마다 각 기능이 다 다를 것이다.  

여러 CXL Device Type 1/2/3 조합이 가능하므로, 아래로 한정적으로 생각하지 말자. 


CXL Switch Diagram


  • CXL 2.0 부터 추가되어진 기능 
기능 역할
Address Mapping / Routing 어떤 요청이 어느 Type으로 가야 하는지 결정
Coherency Management 여러 Type 2/3 장치가 같은 주소 접근 시 캐시 일관성 유지
QoS / Credit Flow 트래픽 제어 및 우선순위 관리
Memory Pooling / Partitioning 여러 메모리 모듈을 하나의 논리 풀로 묶음
Security (IDE) 각 링크별 암호화 및 키 관리


1.3 Rambus 의 CXL Controller IP 확인  

실제 CXL Controller IP 팔고 있는 곳이 있기에 관련 부분을 보도록 하자 

  • Data Encrytion 의 이해 
AES의 대칭키 이해와 KEY 운영 GCM 확인 

  • CXL Controller IP기능 확인
  1. CXL Controller 3.1 vs CXL 2.0 비교 
  2. CCIX(Cache Coherent Interconnect for Accelerators) Controller  각 기능 
  3. CXL Controller  -> 거의 이게 핵심 
    1. PIPE 부분은 PCIe 와 같이 봐야 할 듯 

  • CXL 2.0 Controller 의 구조 
  1. CXL 2.0 Controller 
    1. CXL Protocol Layer
    2. User Interface Layer
    3. Integrity and Data Encryption (IDE)  -> AES-GCM 방식
    4. Unique Features & Capabilities
  2. CXL 2.0 Controller with AXI Block  
    1. ARM과 AMBA 호환 
  
  • Rambus CXL 2.0 Controller with IDE 
  1. IDE(Encrytion)의 Zero Latency  
    1. AES-256-GCM, GCM 이외 CTR 지원 가능? 
  2. 상위와 CXL 2.0 Controller 와 동일 

  • PCIe 의 구조 
  1. PCIe Contoller 
  2. PCIe Switch 
  3. PCIe Phy
CXL의 이해하려면 PCIe의 Phy를 사용하므로, 이 부분은 어 쩔 수 없이 봐야 할 듯하다 



2.  CXL 의 Cache 이해 

CXL의 Cache 는 아주 중요한 개념이며,  어떻게 보면, CXL 성능 핵심 기능일 듯하다.
즉 Cache 알고리즘에 따라 각 CXL의 성능이 달라질 것이며, 이 부분은 거의 회사마다 민감한 문제가 있을 듯하다. 


2.1  Cache Coherence 의 이해 

  • CPU 입장 의 SMP 관점 
다중 코어의 cache-coherency protocols 이용하여 1개의 Core처럼 사용을 하려 한다면, 어떻게 해야 하지  

  • OS 입장의 SMP vs AMP 관점 
OS 입장에서는 다중 코어일 경우,  SMP vs AMP 어떻게 Scheduling 할 것인지, 즉 방법 
Linux 의 경우, SMP기준으로 많이 사용 

  • CPU Cache Coherence 의 기본이해 
각 독립적인 Cache를 Sync를 맞춰주는 작업이며, 아래 그림을 보면 쉽게 이해 간다.
그럼 Why 사용할까 , ARM 같은 다중 코어 일 때, SMP로 Task Scheduling 하려면,  Cache Coherence의 역할은 중요하다 
이유는 아래같이 여러 Core 같이 동시에 나누어서 작업을 해야 하기 때문이다. 

https://en.wikipedia.org/wiki/Cache_coherence#Overview


  • Cache Coherence 의 문제
각 CPU  Cache의 Coherence를 맞추어 주는 것은 좋으나, Cache Coherence의 범위를 예측을 못하는 문제가 발생하다. 
SMP 기준으로 간단히 생각을 해보면, 
모든 CPU의 Cache가 Coherence되어, 1/2번째 CPU는 작업을 나누어 완료 후, 3번째 CPU의 Cache 오래되어, 이제 필요가 없어지는 문제이다. 

  • Cache Coherence 의 개인 생각 정리 
결과적으로, Cache Coherence 범위, Cache 사이즈 및 갯 수 정확하게 제대로 예측 못하면, Cache의 Hit 율이 계속 떨어지고 효율은 낮다. 
어떻게 보면, Cache 예측과 Coherence 범위가 가장 중요할 듯 하다 

좀 더 세부적으로 Cache Coherence 생각해보면, 아직 아래 Protocol도 이해를 못했지만, 
Cache Coherence 운영을 하는 입장에서 생각을 해보면, 다음과 같은 생각도 얼마든지 해볼 수 있다.  
  1. Cache Coherence를 3가지로 A.전체/B.부분(범위)/C.제외 이런 식으로 될 것 같기도 하다. 
  2. 가중치(weight,bias)기반으로 매번 Cache Coherence 변경되어지거나 다양하게 생각 할 수 있을 것 같다.
  3. CNN으로 TinyML 사용해서, 가중치 대신해서 사용 가능 할 것 같다. (다양하게 생각이 듦)
이 부분은 Spec 과 나중에 Cache Corency Protocol 이해 후 다시 생각해 보고, 이해해보도록 하자 


ESP32 Cache 와 Memory 비교 
개인적으로 ESP32 CPU 설계를 잘했다고 생각을 하며, ESP-IDF 역시 너무 잘 구현을 해놨다.



2.2 Cache Corency Protocol 

우선적으로 Cache Corency Protocol 이해 하기 위해서 각 Cache 상태들 부터  이해 해보도록 하자  
머리가 나쁘면, 고생이다. 

CAPI(Coherent Accelerator Processor Interface)

  • Cache 의 상태 이해 
Cache Coherency Protocol States 
상태 약어 의미 설명 
M Modified / D / Dirty / DE / EM - 한 개의 캐시에만 존재하고 수정된(Dirty) 상태
- 메모리 내용은 오래된 값 (아직 반영 안 됨)
- 교체 시 반드시 Write-back 필요
O Owner / SD / SM / T - 여러 캐시에 복사본 존재하지만 메모리는 오래된 값
- 한 캐시만 “소유자(Owner)” 역할
- 다른 캐시의 읽기 요청 시 Owner 캐시가 데이터 공급
E Exclusive / R / VE / EC / Me - 한 캐시만 데이터 보유하고 메모리와 동일(clean)
- 다른 캐시에는 복사본 없음
- 쓰기 시 바로 M(Modified)로 전환
S Shared / V / SC - 여러 캐시에 동일 데이터 복사본 존재
- 주로 읽기 전용(Read-only) 상태
- 메모리와 일관됨 (clean)
- 단, 일부 프로토콜(예: Dragon)은 Shared Clean이 dirty일 수 있음
I Invalid - 유효한 데이터 없음 (태그 불일치 또는 무효화됨)
- 접근 시 메모리나 다른 캐시로부터 새로 읽어와야 함


Special / Extended States (MESI 확장형)
상태 이름 설명
F (또는 R) Forward / Recent - Shared 상태 중 대표 캐시(Forwarder)가 응답 역할 담당
- 동일 데이터가 여러 캐시에 있을 때 메모리 대신 이 캐시가 응답(intervention)
- Intel: MESIF, IBM: R-MESI (MERSI)
H Hover - 캐시에 주소 태그만 유지, 데이터는 무효(Invalid)
- 버스에서 해당 주소가 탐지되면 빠르게 유효(S) 상태로 복귀
- HR-MESI, HRT-MESI 등에서 사용되어 검색 속도 개선


  • Cache Status 요약 비교
상태 캐시에 존재 메모리 최신성 공유 가능성 쓰기 가능성 설명
M ✔ 있음 ✘ 오래됨 ✘ ✔ 수정됨, 아직 메모리 반영 안 됨
O ✔ 있음 ✘ 오래됨 ✔ ✘ 여러 캐시 중 한 곳이 최신 데이터 소유
E ✔ 있음 ✔ 최신 ✘ ✔ 유일한 캐시 복사본, clean 상태
S ✔ 있음 ✔ 최신 ✔ ✘ 여러 캐시에서 읽기만 가능
I ✘ 없음 ✔/✘ 불명 ✘ ✘ 데이터 없음 또는 무효 상태
F ✔ 있음 ✔ 최신 ✔ ✘ 공유 중 대표 캐시(Forwarder)
H 태그만 존재 ✘ ✘ ✘ 주소만 남겨 빠른 재활성 가능


Cache Corency Protocol 의 종류 와 알고리즘 
각 알고리즘의 흐름이 변경되어지는 것을 대충 알 수 있으며, 이 부분은 나중에 좀 더 확인하자.


MESI 의 이해 (대표적)
아직 완벽히 이해가 되지 않은 상태 

MESIF 의 이해 (요즘?)
아직 완벽히 이해가 되지 않은 상태 



3. CXL 의 Linux Manual  

현재 Linux를 잠시 보면, CXL는  Device Type 3으로 메모리 확장용 으로만 사용하는 듯하다. 

  • Linux Device Driver (CXL)
  1. CXL Linux Device Driver 와 Manual 
  2. CXL Device Type 3으로만 사용? 
CXL Device Type 3(Memory 확장용)로만 사용한 것 같으며, Manaul도 거기 까지 인듯하다. 

  • Linux UserSpace
  1. CXL Linux User Manual 
  2. CXL ioctl 이용 


3.1 CXL 의 Linux Kernel 소스 

Linux Kernel 소스 찾아 각 부분 확인 

  • PCI의 ACPI 의 정보 
다만 PCIe가 아닌 PCI 인듯하며, PM 제어는 오래전부터 존재 했던거 같다. 
상위 CXL 1.0 Spec을 보면 PM제어는 부분이 많이 나온다. 

  • BIOS 와 ACPI 관련이해 
BIOS 에서 사용하는 UEFI의  ACPI(Advanced Configuration and Power Interface)  


  • CXL 의 Core 소스 (Linux Kernel)
  1. 상위 Device Type 3 의 Memory 확장형 소스 인것 같음 
  2. Memory 를 보면 주로 모듈형 RAM을 제어 DIMM

  • CXL 의  이외 소스 (Linux Kernel)
  1. 상위 Core 기반으로 Memory 확장형에  ACPI 기술이 첨부
    1. UEFI 의 ACPI(Advanced Configuration and Power Interface)  
  2. PCIe를 그냥 PCI로 기술을 하는 듯함 



상위 Device Driver 와 각 Spec 1.0을 보면서 느낀 점을 정리하자면 아래와 같다. 

  • CXL Switch 의 개인생각 
CXL 관련 Linux Kernel 소스 부분 확인 및 구조 확인 했지만, Device Type 3만 확인되는 듯하며,
CXL Switch Driver(각 CXL Type1/2/3 복합적 연결)는 아직 발견을 못했으며, 
분명, USB Host 처럼 Bus 형태의 Driver 일 것 같은데, 현재 각 제조사마다 다 다를 테니 이것은 초창기 USB Host Controller와 비슷하게 갈 듯하다 

또한, 분명히 CXL Switch가 구조화가 복잡하게 되므로, USB Host처럼 각 Device 의 구조를 설명하는 Description 형태로 각 설정을 변경하는 구조로 갈 듯하다. 왠지?
상위 부분은 Spec을 보고 나중에 다시 생각해보자  


  • CXL 기반의 AI 업체 개인생각 
H/W 입장에서 보면, CXL기반의 AI 업체들의  핵심 개발은 왠지  CPU 와 GPU 와 NPU 의 CXL.cache 가 가장 중요할 듯 하다. 
이유는 SRAM을 가장 효율적으로 빨리 동작 시켜서 DRAM기반으로 VRAM으로 성능 최적화를 하려고 할 것 같다. 

S/W 입장에서 보면, NVIDIA처럼 이제 AI H/W 도 중요하지만, 오히려 S/W Platform의 다각화가 더 중요할 듯하다. 
(NVIDIA 사이트만 가봐도 이해가 되며, Training 대충 경험이 있다면 이해가 더 빠르다)


3.2 Linux 의 Yocto 

Yocto 기반의 Linux에서 CXL 관련부분 을 검색하고 자료 수집 하려 했으나, 아직 제대로 찾지를 못함 
나중에 찾으면, 아래에 링크를 추가하겠음 

  • Yocto 의 기본이해 
Yocto 의 기본이해 



  • Yocto 의 openembedded Layer 확인 
각 최신 버전 과 Layer 확인 했지만, 아직 발견 못함 
CXL Switch 일 경우, 각 Bus Driver가 있어야 할 듯한데, 흐음? 



3.3 Linux 의 QEMU 

Linux Kernel에서 QEMU의 기반의 CXL 부분 확인 

  • QEMU 의 Linux Device Driver (CXL) 
  1. CXL 전체 구조를 보면 역시 Device Type 3 메모리 확장형만 사용 
    1. CXL 2.0  Type.1/2/3 지원 (문제는 Type 3만 사용)
    2. KERNEL CONFIG 확인 
    3. QEMU 으로 동작되는 것을 확인 
      1. 아래 링크 확인

댓글 없음 :
Tags: , , , , ,

11/08/2020

Yocto 의 Licence 정보확인 와 Build Space 구조

1. Yocto의 Licence 정보 와 Build 구조 


Yocto Recipe 작성방법 (반드시 확인 및 이해)

1.1  Yocto Source의 License 설정 

Yocto의 기본인 poky에서 모든 LICENSE를 설정하는 곳이 별도로 존재하며, 
이 기반으로 Recipe에서 선언을 하면 쉽게 License 관리가 된다. 

  • Yocto의 licenses.conf 설정확인 
Yocto의  Source에서 Licenses 관리 부분 SPDXLICENSEMAP 기반으로 Recipe에서 LICENSE로 관리되어짐 

$ vi ./poky/meta/conf/licenses.conf

SRC_DISTRIBUTE_LICENSES += "AAL Adobe AFL-1.2 AFL-2.0 AFL-2.1 AFL-3.0"
SRC_DISTRIBUTE_LICENSES += "AGPL-3.0 ANTLR-PD Apache-1.0 Apache-1.1 Apache-2.0"
SRC_DISTRIBUTE_LICENSES += "APL-1.0 APSL-1.0 APSL-1.1 APSL-1.2 APSL-2.0"
SRC_DISTRIBUTE_LICENSES += "Artistic-1.0 Artistic-2.0 BitstreamVera BSD"
SRC_DISTRIBUTE_LICENSES += "BSD-2-Clause BSD-3-Clause BSD-4-Clause BSL-1.0"
SRC_DISTRIBUTE_LICENSES += "CATOSL-1.1 CC0-1.0 CC-BY-1.0 CC-BY-2.0 CC-BY-2.5"
SRC_DISTRIBUTE_LICENSES += "CC-BY-3.0 CC-BY-NC-1.0 CC-BY-NC-2.0 CC-BY-NC-2.5"
SRC_DISTRIBUTE_LICENSES += "CC-BY-NC-3.0 CC-BY-NC-ND-1.0 CC-BY-NC-ND-2.0"
SRC_DISTRIBUTE_LICENSES += "CC-BY-NC-ND-2.5 CC-BY-NC-ND-3.0 CC-BY-NC-SA-1.0"
SRC_DISTRIBUTE_LICENSES += "CC-BY-NC-SA-2.0 CC-BY-NC-SA-2.5 CC-BY-NC-SA-3.0"
SRC_DISTRIBUTE_LICENSES += "CC-BY-ND-1.0 CC-BY-ND-2.0 CC-BY-ND-2.5 CC-BY-ND-3.0"
SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0 CC-BY-SA-2.5 CC-BY-SA-3.0 CC-BY-SA-4.0"
..........
# AGPL variations
SPDXLICENSEMAP[AGPL-3] = "AGPL-3.0"
SPDXLICENSEMAP[AGPLv3] = "AGPL-3.0"
SPDXLICENSEMAP[AGPLv3.0] = "AGPL-3.0"

# GPL variations
SPDXLICENSEMAP[GPL-1] = "GPL-1.0"
SPDXLICENSEMAP[GPLv1] = "GPL-1.0"
SPDXLICENSEMAP[GPLv1.0] = "GPL-1.0"
SPDXLICENSEMAP[GPL-2] = "GPL-2.0"
SPDXLICENSEMAP[GPLv2] = "GPL-2.0"
SPDXLICENSEMAP[GPLv2.0] = "GPL-2.0"
SPDXLICENSEMAP[GPL-3] = "GPL-3.0"
SPDXLICENSEMAP[GPLv3] = "GPL-3.0"
SPDXLICENSEMAP[GPLv3.0] = "GPL-3.0"

#LGPL variations
SPDXLICENSEMAP[LGPLv2] = "LGPL-2.0"
SPDXLICENSEMAP[LGPLv2.0] = "LGPL-2.0"
SPDXLICENSEMAP[LGPL2.1] = "LGPL-2.1"
SPDXLICENSEMAP[LGPLv2.1] = "LGPL-2.1"
SPDXLICENSEMAP[LGPLv3] = "LGPL-3.0"

#MPL variations
SPDXLICENSEMAP[MPL-1] = "MPL-1.0"
SPDXLICENSEMAP[MPLv1] = "MPL-1.0"
SPDXLICENSEMAP[MPLv1.1] = "MPL-1.1"
SPDXLICENSEMAP[MPLv2] = "MPL-2.0"
.........

Yocto의 License 관리하는 곳 
  https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/conf/licenses.conf

상위 SRC_DISTRIBUTE_LICENSES는 최신 Version에서는 사라짐 
  https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-AVAILABLE_LICENSES
  https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-COMMON_LICENSE_DIR


1.2 Yocto Source의 Receipe 사용방법 

  • 상위 Config 기반으로 Recipe 적용하여 설정 
Recipe 안에서 LICENSE 와 LIC_FILES_CHKSUM로 개별관리가 되므로 주의

Yocto의 Recipe 작성법 혹은 Config 설정확인
  https://ahyuo79.blogspot.com/2020/02/yocto-recipe.html

Openembedded의 Recipe 부분 참조 
  https://www.openembedded.org/wiki/Recipe_License_Fields


2.  Build Space 의 기본구조 확인 

  • Build Space 기본구조 분석 
Build Space 전체 기분구조 확인 
$ tree -t -L 1 --charset unicode
or
$ tree -t -L 1 --charset utf8
.
|-- conf
|-- tmp
|-- sstate-cache
|-- cache
`-- bitbake-cookerdaemon.log

  • Build Space 의 User Config 확인 
Build Space의 User Config 관련사항 

Source의 일반적인 Layer Config

$ tree -t -L 2 --charset unicode conf/   // Build Space의 User Config 
conf/
|-- local.conf.sample
|-- templateconf.cfg
|-- bblayers.conf.org
|-- local.conf
|-- local.conf.org
|-- bblayers.conf
`-- sanity_info

  • Build Space의 tmp 부분 구조

$ tree -t -d -L 2 --charset unicode tmp/
tmp/
|-- hosttools
|-- log
|   `-- cooker
|-- cache
|   `-- default-glibc
|-- stamps
|   |-- all-poky-linux
|   |-- cortexa9hf-neon-mx6sx-poky-linux-gnueabi
|   |-- cortexa9hf-neon-poky-linux-gnueabi
|   |-- imx6sxsabresd-poky-linux-gnueabi
|   |-- x86_64-linux
|   `-- work-shared
|-- work-shared
|   |-- gcc-8.3.0-r0
|   `-- imx6sxsabresd
|-- work
|   |-- cortexa9hf-neon-mx6sx-poky-linux-gnueabi
|   |-- all-poky-linux
|   |-- imx6sxsabresd-poky-linux-gnueabi
|   |-- cortexa9hf-neon-poky-linux-gnueabi
|   `-- x86_64-linux
|-- pkgdata
|   `-- imx6sxsabresd
|-- deploy
|   |-- images
|   |-- rpm
|   `-- licenses
|-- sysroots-components
|   |-- all
|   |-- x86_64
|   |-- cortexa9hf-neon-mx6sx
|   |-- imx6sxsabresd
|   |-- cortexa9hf-neon
|   `-- manifests
|-- buildstats
|   |-- 20201027081937
|   |-- 20201028005722
|   |-- 20201028012636
|   |-- 20201028015306
|   |-- 20201028015422
|   |-- 20201028015551
|   |-- 20201028020411
|   |-- 20201028022652
|   |-- 20201028023144
|   |-- 20201028023437
|   |-- 20201028033851
|   |-- 20201028041736
|   |-- 20201028060743
|   |-- 20201028071633
|   |-- 20201028071841
|   |-- 20201028073336
|   |-- 20201028073710
|   |-- 20201028073849
|   |-- 20201028075408
|   |-- 20201028080901
|   |-- 20201028081657
|   |-- 20201028085730
|   |-- 20201029082105
|   |-- 20201029085354
|   |-- 20201029085549
|   |-- 20201029085755
|   |-- 20201030043736
|   |-- 20201030080459
|   |-- 20201103084648
|   |-- 20201104015257
|   `-- 20201105060918
|-- sysroots
|   `-- imx6sxsabresd
`-- sstate-control



2.1 Build Space에서 License 정보확인 


  • 사용된 Package들의 License 조사

아래와 같이 찾아보면, tmp/deploy/licenses 에 기본적으로 Yocto에서 사용되어지는 Package들 License를 쉽게 찾을 수 있다. 

그 아래를 보면 GCC License가 두 종료로 분리되어 나오

$ find . -name licenses
./tmp/deploy/licenses
./tmp/work/imx6sxsabresd-poky-linux-gnueabi/base-files/3.0.14-r89/licenses
./tmp/work/cortexa9hf-neon-poky-linux-gnueabi/util-linux/2.32.1-r0/util-linux-2.32.1/Documentation/licenses
./tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gnutls/3.6.7-r0/gnutls-3.6.7/lib/extras/licenses
./tmp/work/x86_64-linux/util-linux-native/2.32.1-r0/util-linux-2.32.1/Documentation/license


  • 사용되어지는 Package들의 License 정보확인

Build Space에서 실제 빌드된 Package 정보들이 확인 가능하며, deploy에 배포된 licenses 정보들이 별도로 관리가 되어진다.

이곳에서 관련 licenses 정보들을 확인

$ pwd                 // Yocto의 Build Space 위치 확인 

$ bitbake -h        // Yocto의 Build Space 설정상태확인 

$ ls tmp/deploy/licenses/             // Licenses 에서 사용된 Package 정보들 
acl                                           db                            kmod-native                m4                              qemu-native
alsa-lib                                      db-native                     m4-native                  qemuwrapper-cross
alsa-state                                    dbus                          ldconfig-native            make                            quilt-native
alsa-utils                                    dbus-glib                     libarchive-native          makedevs-native                 quota
attr                                          dbus-glib-native              libassuan-native           make-native                     re2c-native
attr-native                                   dbus-native                   libcap                     mdadm                           readline
autoconf-archive                              dbus-test                     libcheck                   meson-native                    readline-native
autoconf-archive-native                       debianutils-native            libcheck-native            minicom                         rng-tools
autoconf-native                               depmodwrapper-cross           libcomps-native            mklibs-native                   rpcbind
automake-native                               diffutils                     libdaemon                  mobile-broadband-provider-info  rpm-native
avahi                                         dnf-native                    libdnf-native              mpfr-native                     run-postinsts
base-files                                    dosfstools                    libffi                     mtools-native                   sed
base-passwd                                   dosfstools-native             libffi-native              ncurses                         shadow
bash                                          dtc-native                    libgcc                     ncurses-native                  shadow-native
bash-completion                               dwarfsrcfiles-native          libgcc-initial             neard                           shadow-securetty
bc                                            e2fsprogs                     libgcrypt                  netbase                         shadow-sysroot
bc-native                                     e2fsprogs-native              libgpg-error               nettle                          shared-mime-info
binutils                                      elfutils                      libgpg-error-native        ninja-native                    shared-mime-info-native
binutils-cross-arm                            elfutils-native               libical                    nspr-native                     socat
binutils-native                               expat                         libidn2                    nss-native                      sqlite3
bison                                         expat-native                  libjitterentropy           ofono                           sqlite3-native
bison-native                                  file-native                   libmnl                     openssh                         sudo
bluez5                                        firmware-imx                  libmodulemd-native         openssl                         swig-native
bmap-tools-native                             flac                          libmpc-native              openssl-native                  sysfsutils
btrfs-tools                                   flex                          libnl                      opkg-native                     systemd
busybox                                       flex-native                   libnsl2                    opkg-utils                      systemd-compat-units
bzip2                                         gawk                          libnsl2-native             opkg-utils-native               systemd-conf
bzip2-native                                  gcc-cross-arm                 libnss-mdns                optee-client-imx                systemd-serialgetty
ca-certificates                               gcc-runtime                   libogg                     optee-os-imx                    systemd-systemctl-native
chrpath-native                                gdbm                          libpcap                    optee-test-imx                  tcpdump
cmake-native                                  gdbm-native                   libpcre                    os-release                      tcp-wrappers
core-image-base                               gettext-minimal-native        libpcre-native             packagegroup-base               tele-set
core-image-base-imx6sxsabresd-20201027081937 gettext-native                librepo-native             packagegroup-core-boot          texinfo-dummy-native
........

$ ls tmp/deploy/licenses/u-boot-imx/
generic_GPLv2  gpl-2.0.txt  recipeinfo

$ ls tmp/deploy/licenses/gcc-cross-arm/
COPYING  COPYING3  COPYING3.LIB  COPYING.LIB  COPYING.RUNTIME  generic_GPL-3.0-with-GCC-exception  generic_GPLv3  recipeinfo

  • Image에서 사용되어진 License 확인 
사용되어진 Image의 Package들의 License 정보를 알파벳순서로  확인가능하지만, 
주의해야할 것은 모두 나오지는 않으며, 안나오는 것은 상위 Package에서 직접보자.

안나오는 경우는 LICENSE를 CLOSE해버리면 당연히 나오지 않게된다.

나의 경우 간단히 Uboot와 Yocto에서 사용되어지는 Python의 License들은 나오지 않았다.

$ bitbake -e | grep ^MACHINE_ARCH
MACHINE_ARCH="imx6sxsabresd"
MACHINE_ARCH_FILTER="virtual/kernel"

$ bitbake -e | grep ^TUNE_PKGARCH
TUNE_PKGARCH="cortexa9hf-neon"

$ bitbake -e | grep ^IMAGE

$ cat tmp/deploy/licenses/core-image-base-imx6sxsabresd-20201027081937/image_license.manifest
RECIPE NAME: linux-imx
VERSION: 4.19.35
LICENSE: GPLv2
FILES: imx6sx-sdb-ldo--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-mqs--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-btwifi--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-reva-ldo--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-reva--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-lcdif1--4.19.35-r0-imx6sxsabresd-20201028015422.dtb zImage--4.19.35-r0-imx6sxsabresd-20201028015422.bin imx6sx-sdb--4.19.35-r0-imx6sxsabresd-20201028015422.dtb modules--4.19.35-r0-imx6sxsabresd-20201028015422.tgz imx6sx-sdb-sai--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-emmc--4.19.35-r0-imx6sxsabresd-20201028015422.dtb imx6sx-sdb-m4--4.19.35-r0-imx6sxsabresd-20201028015422.dtb

RECIPE NAME: optee-os-imx
VERSION: git
LICENSE: BSD
FILES: uTee-6sxsdb tee.mx6sxsabresd.bin

RECIPE NAME: u-boot-imx
VERSION: 2019.04
LICENSE: GPLv2+
FILES: u-boot-emmc-2019.04-r0.imx


$ cat tmp/deploy/licenses/core-image-base-imx6sxsabresd-20201105060918/package.manifest
alsa-conf
alsa-state
alsa-states
alsa-utils-alsactl
alsa-utils-alsamixer
avahi-daemon
avahi-locale-en-gb
base-files
base-passwd
bash
binutils
bluez5
busybox
busybox-syslog
busybox-udhcpc
db
dbus-1
e2fsprogs-e2fsck
firmware-imx-sdma
glibc-locale-en-gb
imx-alsa-plugins
iptables
iptables-module-ebt-802-3
iptables-module-ebt-ip
iptables-module-ebt-log
iptables-module-ebt-mark-m
iptables-module-ip6t-ah
iptables-module-ip6t-dnat
iptables-module-ip6t-dnpt
iptables-module-ip6t-dst
iptables-module-ip6t-eui64
iptables-module-ip6t-frag
iptables-module-ip6t-hbh
iptables-module-ip6t-hl
iptables-module-ip6t-icmp6
iptables-module-ip6t-ipv6header
iptables-module-ip6t-log
iptables-module-ip6t-masquerade
......

$ cat tmp/deploy/licenses/core-lora-image-imx6sxsabresd-20201027081937/license.manifest
PACKAGE NAME: alsa-conf
PACKAGE VERSION: 1.1.8
RECIPE NAME: alsa-lib
LICENSE: LGPLv2.1 & GPLv2+

PACKAGE NAME: alsa-lib
PACKAGE VERSION: 1.1.8
RECIPE NAME: alsa-lib
LICENSE: LGPLv2.1 & GPLv2+

PACKAGE NAME: alsa-state
PACKAGE VERSION: 0.2.0
RECIPE NAME: alsa-state
LICENSE: MIT

PACKAGE NAME: alsa-states
PACKAGE VERSION: 0.2.0
RECIPE NAME: alsa-state
LICENSE: MIT

PACKAGE NAME: alsa-utils-alsactl
PACKAGE VERSION: 1.1.8
RECIPE NAME: alsa-utils
LICENSE: GPLv2+

PACKAGE NAME: alsa-utils-alsamixer
PACKAGE VERSION: 1.1.8
RECIPE NAME: alsa-utils
LICENSE: GPLv2+

PACKAGE NAME: avahi-daemon
PACKAGE VERSION: 0.7
RECIPE NAME: avahi
LICENSE: GPLv2+ & LGPLv2.1+

PACKAGE NAME: avahi-locale-en-gb
PACKAGE VERSION: 0.7
RECIPE NAME: avahi
LICENSE: GPLv2+ & LGPLv2.1+

PACKAGE NAME: base-files
PACKAGE VERSION: 3.0.14
RECIPE NAME: base-files
LICENSE: GPLv2

PACKAGE NAME: base-passwd
PACKAGE VERSION: 3.5.29
RECIPE NAME: base-passwd
LICENSE: GPLv2+
......


댓글 없음 :
Tags: ,

4/22/2020

Yocto User Config 의 Profiling and Tracing

1. Yocto 의 Profile 기능 추가 및 사용

Yocto 기반으로 Profile 기능과 Trace Debug기능을 추가하여 사용하는 방법을 알아보기 위해서 아래와 같이 설정변경 후,
이를 기반으로 Profile 과 Tracing 사용을 해본다.

Yocto에서 Profile 과 Tracing은 소스를 세부적으로 분석하는 Debug 기술이자, 성능측정도 가능하므로 중요한 기술이다. 
이를 제대로 사용하려면 각 IDE Tool 도 알아두어야 한다
대부분 Ecplise 기반으로 제공되어지며, 각 Chip 제조사 Application들도 보면 기반을 다 Ecplise 기반으로 되어있다. 


TI CCS (TI사 제공) 이외 각 제조사 IDE 참조 


1.1 Yocto 의 기본문법 및 User Config 이해 

Yocto의 기본적인 이해


Yocto Recipe 작성방법 (반드시 확인 및 이해)

Yocto User Configuration 수정방법
  https://ahyuo79.blogspot.com/2020/02/yocto-user-configuration.html

기본 Yocto Recipe 및 Kernel Recipe 수정방법
  https://ahyuo79.blogspot.com/2020/02/yocto-recipe.html

Yocto sysLog 구성 
  https://ahyuo79.blogspot.com/2020/04/yocto-syslogd.html


1.2  Yocto User Configuration 설정변경 

  • Yocto 의 User Configuration 수정 
$ cat conf/local.conf  //일반적인 설정

## Yocto Version에따라 설정변경될 수 있음 아래 Manual 참조
## 일반적인 EXTRA_IMAGE_FEATURES 설정으로 debug 기본정보포함 (기본 /sys/kernel/debug는 동작됨)
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

별도로 추가하여 설정
## Profile 과 Tracing 을 위해 별도로 추가되는 명령들 
## IMAGE의 Profile Tool을 추가 
EXTRA_IMAGE_FEATURES += "tools-profile"

## Package들에 Debug 정보를 추가 (bitbake를 이용하여 xxx-dbg Manual로 해도됨)
EXTRA_IMAGE_FEATURES += "dbg-pkgs"

## Yocto는 default로 strip을 하여 debug정보 및 삭제하므로 이를 방지 
INHIBIT_PACKAGE_STRIP = "1"

##  *-dbg packages 만들 때 Bin 와 Debug 정보를 어떻게 분리할지를 결정 (bin 에 .debug 생성) 
PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'

** EXTRA_IMAGE_FEATURES 는 항상 Yocto Version에 따라 반드시 참조 

gdb 와 같이 사용하고자 하면 아래와 같이 설정 
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
EXTRA_IMAGE_FEATURES += "tools-debug"

Yocto에서 deb 방식으로 package 관리할 경우 (apt-get)
  https://imxdev.gitlab.io/tutorial/How_to_apt-get_to_the_Yocto_Project_image/
 
EXTRA_IMAGE_FEATURES 
  https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-features-image


1.3 Yocto 의 Kernel Config 수정 

  • WORKDIR 에서 현재 Kernel Config 확인
Yocto의 Build space에서 직접 빌드된 Kernel Source의 Config 확인

$ vi ./tmp/work/imx6sxsabresd-poky-linux-gnueabi/linux-imx/4.19.35-r0/build/.config  //직접 찾아서 확인 
CONFIG_BUILD_LTTNG       //확인했으나 없음
CONFIG_FUNCTION_TRACER   //확인했으나 없음 

$ vi ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-kernel/linux/linux-imx_4.19.35.bbappend // Kernel Recipe가 문제가 있음 
# 부분 막음 
do_preconfigure_append()

  https://en.wikipedia.org/wiki/Ftrace


  • Kernel 의 CONFIG 설정변경 

$ bitbake linux-imx  -c configme    // patch 후 *cfg를 적용을 한다고하는데, 동작안됨
$ bitbake linux-imx  -c menuconfig    // 설정변경
//각 메뉴 선택 후 HELP에서 CONFIG 확인가능

//이미 설정되어있음 
> Kernel hacking > Compile-time checks and compiler options > Debug Filesystem (CONFIG_DEBUG_FS)

//새로설정 
> Kernel hacking > Tracers                                            // (CONFIG_FTRACE)
> Kernel hacking > Tracers > Kernel Function Tracer                  // (CONFIG_FUNCTION_TRACER)
> Kernel hacking > Tracers > Kernel Function Graph Tracer            // (CONFIG_FUNCTION_GRAPH_TRACER)
> Kernel hacking > Tracers > Interrupts-off Latency Tracer           // (CONFIG_IRQSOFF_TRACER)
> Kernel hacking > Tracers > Preemption-off Latency Tracer           // (CONFIG_PREEMPT_TRACER)
> Kernel hacking > Tracers > Scheduling Latency Tracer               // (CONFIG_SCHED_TRACER)
> Kernel hacking > Tracers > Trace max stack                         // (CONFIG_STACK_TRACER)
> Kernel hacking > Tracers > Support for tracing block IO actions    // (CONFIG_BLK_DEV_IO_TRACE)
> Kernel hacking > Tracers > Kernel function profiler                // (CONFIG_FUNCTION_PROFILER)
CONFIG_DYNAMIC_FTRACE="y"                                              // 찾지못함 (상위 설정시 자동설정됨)
CONFIG_FTRACE_MCOUNT_RECORD="y"                                        // 찾지못함 (상위 설정시 자동설정됨)


//추후 별도로 추가 
> Kernel hacking > Tracers > Trace syscalls                          // (CONFIG_FTRACE_SYSCALLS)

fragment가 생성되었으나 이전 .config 의 나의 설정과 다름 (주의)
추후 필요한 것만 직접 적용하여 넣도록하자

$ bitbake linux-imx  -c diffconfig    //*.cfg 생성 후 이를 Kernel Recipe에 추가 
....
......../fragment.cfg

$ cat fragment.cfg  // 상위와 다르게 나옴 자세히 보면 선택한 것도 미선택으로 됨 
CONFIG_TRACEPOINTS=y
CONFIG_UPROBES=y
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_ATH6KL_TRACING is not set
# CONFIG_MXC_GPU_VIV is not set
CONFIG_BINARY_PRINTF=y
# CONFIG_DEBUG_PAGE_REF is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
CONFIG_NOP_TRACER=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_PREEMPTIRQ_TRACEPOINTS=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
# CONFIG_FUNCTION_GRAPH_TRACER is not set
CONFIG_TRACE_PREEMPT_TOGGLE=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
CONFIG_IRQSOFF_TRACER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
# CONFIG_HWLAT_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_TRACER_SNAPSHOT=y
CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_UPROBE_EVENTS=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_TRACEPOINT_BENCHMARK is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
# CONFIG_TRACE_EVAL_MAP_FILE is not set
CONFIG_TRACING_EVENTS_GPIO=y

$ cp ./build/tmp/work/imx6sxsabresd-poky-linux-gnueabi/linux-imx/4.19.35-r0/fragment.cfg ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-kernel/linux/files/kernel_ftrace.cfg
//적용 Kernel Recipe 수정

ftrace 의 Kernel config 설정
  https://stackoverflow.com/questions/41238386/how-to-enable-or-configure-ftrace-module
  https://docs.google.com/presentation/d/13zIFUTTdChr7JNpZnb1K56aUsv_E1cOWausjQpsqcGc/htmlpresent
  https://docs.windriver.com/bundle/Wind_River_Linux_Tutorial_Dynamic_Kernel_Debugging_with_ftrace_and_kprobes_LTS_1/page/zjd1552591139310.html

  • Kernel 만 다시빌드 및 배포

$ bitbake linux-imx  -c compile -f    // -f force로 강제로 빌드 후 .config 설정확인 
$ bitbake linux-imx  -c deploy        // 이를 적용 

$ bitbake linux-imx  -c clean        // 전체삭제 
$ bitbake linux-imx          // 전체동작 (오동작) 
$ bitbake linux-imx  -c configure         // 전체동작 (오동작)


  https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-KBUILD_DEFCONFIG
  https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#kernel-related-tasks

  • bitbake로 image 생성
$ bitbake core-image-base


Yocto Profile manual
Zeus(3.0)
  https://yoctoproject.org/docs/3.0/profile-manual/profile-manual.html
Warrior(2.7)
  https://yoctoproject.org/docs/2.7/profile-manual/profile-manual.html
Fido(1.8)
  https://yoctoproject.org/docs/1.8/profile-manual/profile-manual.html


1.4  Yocto 설정 변경 시 문제사항 

  • 처음 발생하는 문제
Parition을 고정 크기를 했을 경우, Debug 정보가 들어가기 때문에 나의 경우는 약 4배 좀 더 용량이 더 커져서 문제발생
이 문제는 아래의 WIC 부분 참조

  • 두번째 발생하는 문제
빌드가 잘 된 후 아래와 같이 Image를 적용 후 Booting 하며 문제발생
아래문제도 역시 /var/log 와 kernel size 문제를 제거후 해결됨
.......
         Starting Flush Journal to Persistent Storage...
systemd-journald[164]: Received request to flush runtime journal from PID 1
[  OK  ] Started Flush Journal to Persistent Storage.
[    **] A start job is running for dev-mmcblk3p5.device (24s / 1min 30s)random: crng init done
random: 7 urandom warning(s) missed due to ratelimiting
[ TIME ] Timed out waiting for device dev-mmcblk3p5.device.

  https://www.linode.com/community/questions/17915/why-did-my-server-miss-urandom-warnings-due-to-rate-limiting


Yocto 의 WIC Partition (해결방법)
  1. Partition Size도 가변사이즈로 변경(고정사이즈일 경우) 
  2. Partition 도 삭제했다면 sources에서도 fstab도 같이 수정 
  3. /var/log 부분기능삭제
  https://ahyuo79.blogspot.com/2020/02/yocto-partition.html


2. Yocto의 Profile 및 Trace 확인 및 사용


  • 현재 설정된 기본기능확인 (EXTRA_IMAGE_FEATURES 확인)

$ cat /etc/fstab    // /sys/debug/kernel 별도로 없으며, 상위 debug-tweaks 참조  

$ ls /sys/kernel/debug  // 상위 (EXTRA_IMAGE_FEATURES ?= "debug-tweaks") 적용 부터 동작 
2100000.caam/       extfrag/            pm_genpd/
bdi/                fault_around_bytes  pm_qos/
block/              gpio                pwm
ci_hdrc.0/          hid/                regmap/
ci_hdrc.1/          iio/                regulator/
clear_warn_once     memblock/           sleep_time
clk/                mmc2/               suspend_stats
device_component/   mmc3/               ubi/
devices_deferred    mtd/                ubifs/
dma_buf/            opp/                usb/
dri/                pinctrl/            wakeup_sources

$ cat /sys/kernel/debug/gpio  // GPIO Debug   (sysfs도 이용하지만, device tree에서 직접 모듈로 연결가능) 
....
 gpio-112 (                    |peri_3v3            ) out hi  // sys file이 아닌 device tree에서 gpio 연결 
 ...
 gpio-114 (                    |sysfs               ) out lo         
 ...
 gpio-160 (                    |sysfs               ) out hi  // sys file에서 export 한 다음 direction 설정 후 값 설정
 gpio-161 (                    |sysfs               ) out hi
 gpio-170 (                    |spi_imx             ) out hi

// PinCtrl 관련설정값을 쉽게 확인 (device tree의 설정값과 비교) 
$ cat /sys/kernel/debug/pinctrl/pinctrl-handles 

// PinCtrl 관련설정값을 세부적으로 확인 (device tree의 설정값과 비교) 
$ cat /sys/kernel/debug/pinctrl/pinctrl-maps 

// USB 정보 lsusb 
$ cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  1, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.19
S:  Manufacturer=Linux 4.19.35-1.1.0+g0f9917c ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=ci_hdrc.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms 
......

// PMIC Regulator 정보 
$ ls /sys/kernel/debug/regulator/   
0-0008-COIN
0-0008-SW1AB
0-0008-SW2
0-0008-SW3A
0-0008-SW3B
0-0008-SWBST
0-0008-VGEN1
0-0008-VGEN2
0-0008-VGEN3
0-0008-VGEN4
0-0008-VGEN5
0-0008-VGEN6
0-0008-VREFDDR
0-0008-VSNVS
.......



$ perf  // EXTRA_IMAGE_FEATURES 추가설정 후 존재확인

$ lttng           // lttng          확인
$ lttng-crash     // lttng-crash    확인
$ lttng-relayd    // lttng-relayd   확인
$ lttng-sessiond  // lttng-sessiond 확인

$ babeltrace      // babeltrace 확인
$ babeltrace-log  // babeltrace-log

$ blktrace  //blktrace  존재확인  (Block Device Trace) 
$ blkparse  //blkparse  존재확인   
$ iowatcher  //blktrace  visual tool   

$ dtrace  //dtrace  


$ ls /sys/kernel/debug/tracing  // 미존재하면 Kernel Config 수정 필요 
README                      set_ftrace_filter
available_events            set_ftrace_notrace
available_filter_functions  set_ftrace_pid
available_tracers           snapshot
buffer_size_kb              stack_max_size
buffer_total_size_kb        stack_trace
current_tracer              stack_trace_filter
dyn_ftrace_total_info       timestamp_mode
enabled_functions           trace
events                      trace_clock
free_buffer                 trace_marker
function_profile_enabled    trace_marker_raw
instances                   trace_options
options                     trace_pipe
per_cpu                     trace_stat
printk_formats              tracing_cpumask
saved_cmdlines              tracing_max_latency
saved_cmdlines_size         tracing_on
saved_tgids                 tracing_thresh
set_event                   uprobe_events
set_event_pid               uprobe_profile


2.1 Ftrace의 기본동작 확인 


$ mount -t debugfs nodev /sys/kernel/debug

$ echo 1 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable
$ echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable
$ echo 1 > /sys/kernel/debug/tracing/events/syscalls/enable

## Start Recording 
$ echo 1 > /sys/kernel/debug/tracing/tracing_on

$ cat /sys/kernel/debug/tracing/trace > myFtraceFile.txt


$ cat myFtraceFile.txt  | head -n 20
# tracer: nop
#
# entries-in-buffer/entries-written: 6606/6606   #P:1
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          <idle>-0     [000] dns4  2163.718052: sched_wakeup: comm=rcu_preempt pid=10 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.718080: sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.728019: sched_wakeup: comm=rcu_preempt pid=10 prio=120 target_cpu=000
          <idle>-0     [000] dnH5  2163.728046: sched_wakeup: comm=kworker/0:0 pid=342 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.728068: sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.738009: sched_wakeup: comm=rcu_preempt pid=10 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.738035: sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.758001: sched_wakeup: comm=kworker/0:0 pid=342 prio=120 target_cpu=000
          <idle>-0     [000] dns4  2163.768017: sched_wakeup: comm=rcu_preempt pid=10 prio=120 target_cpu=000


  https://archive.eclipse.org/tracecompass.incubator/doc/org.eclipse.tracecompass.incubator.ftrace.doc.user/User-Guide.html
  https://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/Trace-Compass-Main-Features.html
  https://archive.eclipse.org/tracecompass.incubator/doc/org.eclipse.tracecompass.incubator.kernel.doc.user/User-Guide.html


2.2 LTTng 사용방법

아래와 같이 Ecplise를 이용하여 LTTng와 함께 쉽게 디버깅가능  

  • LTTng Command 사용법 및 Trace Compass or Ecplise에서 분석

$ lttng create mySession  // Trace Compass or Ecplise 의 LTTng의 Control의 SSH로 접속가능 

$ lttng enable-event sched_switch -k   // Trace Compass의 Control의 Provider의 Kernel에서도 설정가능 

$ lttng start // Trace Compass의 Control의 Session의 mySession에서 Start 가능 

$ lttng stop // Trace Compass의 Control의 Session의 mySession에서 Stop 가능 

$ lttng view // Consol에서 정보보기 

$ lttng destroy mySession  // 본인이 필요 없다면 삭제 , 분석을 한다면 미삭제 

$ tar cvzf lttngtest.tar.gz lttng-traces   // 이안에 상위에서 만든 각각의 Session들이 존재



  • Ecplise 에서 LTTng 분석 
  1. LTTng->Control에서는 SSH로 Target에 연결하여 Control로 가능 
  2. lttng create Session만 진행 후 모든 것을 Remote로 진행가능 
  3. 상위에서 저장된 lttngtest.tar.gz 정보를 Trace Project에서 import하여 분석가능도 가능 


관련참조자료 
  https://www.nxp.com/docs/en/application-note/AN5172.pdf


3. EXTRA_IMAGE_FEATURE의 확장 설정 

User Config의 local config 부분에 확장추가 
$ cat conf/local.conf
## Yocto Profile Manual 부분의 참고 (미테스트)
## Profile Tool (perf, systemtap, and LTTng ) 설치  (Warrior 사용가능)
EXTRA_IMAGE_FEATURES += "perf"

## Debugging Tool 설치 ( strace and gdb)  (Warrior 사용가능)
EXTRA_IMAGE_FEATURES += "tools-debug"

  https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#General_Setup
  https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#Collecting_and_viewing_a_trace_in_Eclipse



  • IMAGE_FEATURE  기능의 변화
사용되는 Yocto의 Version에 따라 IMAGE FEATURE의 기능이 다르므로 주의

Zeus(3.0)
  https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#ref-features-image
Warrior(2.7)
  https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#ref-features-image
Fido(1.8)
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-features-image


Yocto SDK Manual
  https://www.yoctoproject.org/docs/2.7/sdk-manual/sdk-manual.html


Intel Vtune
  https://software.intel.com/content/www/us/en/develop/documentation/vtune-help/top/set-up-analysis-target/embedded-linux-targets/configure-yocto-project-with-linux-target-package.html
  https://software.intel.com/content/www/us/en/develop/documentation/vtune-help/top.html
댓글 없음 :
Tags: , , , ,

4/05/2020

Yocto 에서 syslogd/logrotate 와 Package 중복사용

1. syslogd 와 logrotate 관련 사항 

syslogd 관련이해
Yocto에 추가하기 전에 syslog를 먼저 이해하도록하자 


Yocto Recipe 작성방법 


Yocto에서 syslogd를 사용할 경우 일반적으로 busybox에 포함된 package로 많이 사용할 것이며, 그 기준으로 설명한다.

기본적으로 syslogd 와 logrotate 는 busybox에서 제공해주지만, 완벽한 기능이 아니라서 별도로 각가 설치를 해주면 된다. 

  • logrotate package 지원
busybox에서도 logrotate를 지원해주지만, logrotate package를 설치하는 것이 더 좋다 

IMAGE_INSTALL += "logrotate"

  • rsyslogd or syslog-ng package 지원 
busybox의 syslogd가 기본지원이지만 확장하고자 하면 설정하며, ubuntu가 rsyslogd 사용하여 나중에 이것으로 사용
IMAGE_INSTALL += "rsyslog"

1.1. busybox의 사용할 경우 한계


busybox의 syslogd의 경우 좀 특별하게 설정이 되며, 설정에 따라 rotate의 기능이 기본제공이 되며 아래와 같이 동작된다.
예를들면, 200K 기준으로 2개의 Message들을 보관하고 2개로 Rotate를 진행하는데, 이 부분은 아래의 소스를 참조
  1. /var/log/messages    (latest)
  2. /var/log/messages.0  (200k까지 보관)

busybox 소스에서 200K로 1번의 rotate가 가능하며, 이부분은 소스에서 직접수정가능

이 busybox의 rotate 기능은  logrotate기능과는 너무 부족하므로 , logrotate를 별도로 사용할 경우 사용중지하는 것이 맞을 것 같다. 

/var/log/messages.0 관련내용 
  https://www.unix.com/unix-for-dummies-questions-and-answers/183205-why-there-var-adm-messages-0-messages-1-messages-2-messages-3-a.html


  • busybox-syslogd 와 rotate 기능 소스분석 
busybox의 syslogd 소스를 분석을 해보면 아래와 같이 200K 저장되는 Logrotate기능이 내부에 별도로 존재한다.
busybox 말고 별도의 Logrotate Package를 사용하고자 하면 CONFIG_FEATURE_ROTATE_LOGFILE 부분을 막자

.........
//config:config SYSLOGD
//config:	bool "syslogd (13 kb)"
//config:	default y
//config:	help
//config:	The syslogd utility is used to record logs of all the
//config:	significant events that occur on a system. Every
//config:	message that is logged records the date and time of the
//config:	event, and will generally also record the name of the
//config:	application that generated the message. When used in
//config:	conjunction with klogd, messages from the Linux kernel
//config:	can also be recorded. This is terribly useful,
//config:	especially for finding what happened when something goes
//config:	wrong. And something almost always will go wrong if
//config:	you wait long enough....
//config:config FEATURE_ROTATE_LOGFILE
//config:	bool "Rotate message files"
//config:	default y
//config:	depends on SYSLOGD
//config:	help
//config:	This enables syslogd to rotate the message files
//config:	on his own. No need to use an external rotate script.
.........
typedef struct logFile_t {
	const char *path;
	int fd;
	time_t last_log_time;
#if ENABLE_FEATURE_ROTATE_LOGFILE
	unsigned size;
	uint8_t isRegular;
#endif
} logFile_t;
.....

#if ENABLE_FEATURE_ROTATE_LOGFILE      // LOG 사이즈 200K 확인 
 .logFileSize = 200 * 1024,
 .logFileRotate = 1,
#endif

......

ENABLE_FEATURE_ROTATE_LOGFILE 관련소스확인
  https://git.busybox.net/busybox/tree/sysklogd/syslogd.c

  • Yocto 의 Busybox 관련 Recipe 분석

$ find . -name busybox*bb*  // Yocto의 busybox recipe 모두 확인하며, 중복되면 Version 높은것만 확인  
./meta-fsl-bsp-release/imx/meta-bsp/recipes-core/busybox/busybox_%.bbappend  // 3. 최종 bbappend 확인  
./poky/meta/recipes-core/busybox/busybox_1.30.1.bb        // 1. Main busybox recipe 
./poky/meta/recipes-core/busybox/busybox-inittab_1.30.1.bb       // SysVinit 일 경우 /etc/inittab 사용, 미사용
./poky/meta-skeleton/recipes-core/busybox/busybox_%.bbappend
./poky/meta-poky/recipes-core/busybox/busybox_%.bbappend  // 2. Main busybox recipe의 bbappend 반드시 확인  

// 1.Main busybox recipe 기반으로 분석 및 관련 cfg 와 patch 확인
$ cat ./poky/meta/recipes-core/busybox/busybox_1.30.1.bb  
require busybox.inc

SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
           file://busybox-udhcpc-no_deconfig.patch \
           file://find-touchscreen.sh \
           file://busybox-cron \
           file://busybox-httpd \
           file://busybox-udhcpd \
           file://default.script \
           file://simple.script \
           file://hwclock.sh \
           file://mount.busybox \
           file://syslog \
           file://syslog-startup.conf \
           file://syslog.conf \
           file://busybox-syslog.default \
           file://mdev \
           file://mdev.conf \
           file://mdev-mount.sh \
           file://umount.busybox \
           file://defconfig \
           file://busybox-syslog.service.in \
           file://busybox-klogd.service.in \
           file://fail_on_no_media.patch \
           file://run-ptest \
           file://inetd.conf \
           file://inetd \
           file://login-utilities.cfg \
           file://recognize_connmand.patch \
           file://busybox-cross-menuconfig.patch \
           file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \
           file://mount-via-label.cfg \
           file://sha1sum.cfg \
           file://sha256sum.cfg \
           file://getopts.cfg \
           file://resize.cfg \
           ${@["", "file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'busybox')]} \
           ${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') == 'busybox-mdev')]} \
           file://syslog.cfg \
           file://inittab \
           file://rcS \
           file://rcK \
           file://makefile-libbb-race.patch \
           file://0001-testsuite-check-uudecode-before-using-it.patch \
           file://0001-testsuite-use-www.example.org-for-wget-test-cases.patch \
           file://0001-du-l-works-fix-to-use-145-instead-of-144.patch \
           file://0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch \
"
SRC_URI_append_libc-musl = " file://musl.cfg "

SRC_URI[tarball.md5sum] = "4f72fc6abd736d5f4741fc4a2485547a"
SRC_URI[tarball.sha256sum] = "3d1d04a4dbd34048f4794815a5c48ebb9eb53c5277e09ffffc060323b95dfbdc"

$ cat ./poky/meta-poky/recipes-core/busybox/busybox_%.bbappend // 2. Main busybox recipe의 bbappend 반드시 확인  
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
///BPN 은 일반적으로 PN Package Name 의 Version 이라고 하는데 다만 prefix 와 suffix가 제거된상태 

$ ls ./poky/meta-poky/recipes-core/busybox/  // bbappend 에 적용되는 busybox directory 확인  
busybox  busybox_%.bbappend

// 3. 최종 bbappend 과 관련파일 반드시 확인  
$ cat ./meta-fsl-bsp-release/imx/meta-bsp/recipes-core/busybox/busybox_%.bbappend 

# look for files in the layer first
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://ftpget.cfg"

// Yocto의 경우 다른 *.cfg / *.patch 
$ ls ./poky/meta/recipes-core/busybox/busybox/


1.2. busybox의 logrotate 제거 

  • Busybox의 Config 설정변경 (Yocto)
기본 config에서 CONFIG_FEATURE_ROTATE_LOGFILE 설정제거(*.cfg 이용)
이미 IMAGE_INSTALL에 logrotate 추가했다면 상위 CONFIG를 제거

$ cat ./poky/meta-poky/recipes-core/busybox/busybox/poky-tiny/defconfig  // 기본 busybox Config
...
#
# System Logging Utilities
#
CONFIG_SYSLOGD=y
CONFIG_FEATURE_ROTATE_LOGFILE=y
CONFIG_FEATURE_REMOTE_LOG=y
CONFIG_FEATURE_SYSLOGD_DUP=y
CONFIG_FEATURE_SYSLOGD_CFG=y
CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256
CONFIG_FEATURE_IPC_SYSLOG=y
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
CONFIG_LOGREAD=y
CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
CONFIG_KLOGD=y
CONFIG_FEATURE_KLOGD_KLOGCTL=y
CONFIG_LOGGER=y

// Recipe의 *.cfg의 추가 config가 존재한다면, 이 값에 따라 변경 (주의)
$ cat ./poky/meta/recipes-core/busybox/busybox/syslog.cfg 
CONFIG_SYSLOGD=y
# CONFIG_FEATURE_ROTATE_LOGFILE is not set
CONFIG_FEATURE_REMOTE_LOG=y
CONFIG_FEATURE_SYSLOGD_DUP=y
CONFIG_FEATURE_SYSLOGD_CFG=y
CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256
CONFIG_FEATURE_IPC_SYSLOG=y
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=64
CONFIG_LOGREAD=y
CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
CONFIG_FEATURE_KMSG_SYSLOG=y

설정참고
  https://stackoverflow.com/questions/41868231/how-to-setup-syslog-in-yocto

  • syslog.conf 관련설정 부분 확인

$ find . -name syslog.conf
$ cat ./poky/meta/recipes-core/busybox/files/syslog.conf     // 이곳에서 /etc/syslog.conf 수정하면 적용됨
$ cat ./poky/meta/recipes-extended/sysklogd/files/syslog.conf  // /etc/syslog.conf 확장이라고 추정 

// sysVinit 일 경우, systemd만 사용할 경우는 제외(추후 확인)
$ cat ./poky/meta/recipes-core/busybox/files/syslog-startup.conf   
# This configuration file is used by the busybox syslog init script,
# /etc/init.d/syslog[.busybox] to set syslog configuration at start time.

DESTINATION=file  # log destinations (buffer file remote)
LOGFILE=/var/log/messages # where to log (file)
REMOTE=loghost:514  # where to log (syslog remote)
REDUCE=no   # reduce-size logging
DROPDUPLICATES=no  # whether to drop duplicate log entries
#ROTATESIZE=0   # rotate log if grown beyond X [kByte]
#ROTATEGENS=3   # keep X generations of rotated logs
BUFFERSIZE=64   # size of circular buffer [kByte]
FOREGROUND=no   # run in foreground (don't use!)
#LOGLEVEL=5   # local log level (between 1 and 8)


yocto 사용시 busybox syslogd 설정
  https://stackoverrun.com/ko/q/11519947


2. busybox 이외 Package 사용시 문제사항


Linux에서 필요한 기본 Util들을 다루며, Embedded에서는 대부분 BusyBox를 사용하지만, 좀 더 나은 binary를 사용하고자 하면, 
util-linux 와 각 Package들이 겹치고 다른 Package들과 겹치는 문제가 자주 생긴다. 


2.1 util-linux 와 busybox package 중복될 경우 

Yocto 내부에서 Package가 중복이 될 때 사용하는 class로 update-alternatives.class를 사용하며, 이 부분을 이해하자.

  • util-linux 의 Package List
Util Linux의 Package 관련사항 
  https://en.wikipedia.org/wiki/Util-linux


  • util-linux Package 추가 (중요)
대부분 Yocto에서 core-Image-base로 build 할 경우 util-linux를 미사용을 하는데, busybox대신 혹은 같이 사용할 경우 반드시 추가

IMAGE_INSTALL += "util-linux"


  • update-alternatives 관련사항
util-linux을 보면 동일한 프로그램이 여러 Package에서 중복 설치가 발생할 수 있으므로, 각각의 중복이 될 경우 대체(ALTERNATIVE)를 사용하여, 이를 해결하도록 한다.  

특히 busybox 와 binutils 와 util-linux 부분이 될 것 같으며, 이런 Package가 설치가 되어 중복이 되는 것을 피하기 위해서 이 class를 사용한다.
피하는 방법은 rename 방식으로 이를 link를 만들어 사용하는 것이므로 기본 사용법은 알아두자.
   
  ALTERNATIVE : 중복이 될 경우 대체가 될 command들을 기술 
  ALTERNATIVE_LINK_NAME: 중복이 되면 실제 위치들을 각 기술 
  ALTERNATIVE_PRIORITY: 중복이 되면, 이값을 각 기술하여 설치 우선순위 결정  
  ALTERNATIVE_TARGET: 기본으로 ALTERNATIVE_LINK_NAME값과 동일하며, 링크생성

Warrior(2.7)
Fido(1.8)



2.2 util-linux recipe 소스 분석 (intel)

먼저 IMAGE_INSTALL 에 util_linux가 추가되어있어야 동작가능하며,  busybox 설치되어있는 경우, 각 설정을 ALTERNATIVE로 설정  

  • util-linux 기본분석 (Intel Yocto)
  1. SRC_URI를 이용하여 util-linux 소스 download
  2. PACKAGES 에 사용하고자하는 util-linux-xxx PACKAGE들을 추가 
  3. FILE_util-linux-xxxx 사용할 PACKAGE들의 저장장소 설정 
  4. ALTERNATIVE_PRIORITY 전체 대체될 Package들 우선순위 busybox 조율 
  5. ALTERNATIVE_${PN} 안에 대체가 될 Package 들 기술
  6. ALTERNATIVE_util-linux-hwclock 상위와 동일하지만, PN 직접기술 
  7. ALTERNATIVE_LINK_NAME busybox 의 것들을 기술
  8. ALTERNATIVE_TARGET  default link를 생성하여 실제 사용결정   
Intel의 Yocto는 busybox 와 겹치는 경우 util-linux 실제 설정 


2.3 util-linux recipe 소스 분석 (poky)

먼저 IMAGE_INSTALL 에 util_linux가 추가되어있어야 동작하며, 기본소스를 보면 대체적으로, 이미 busybox 설치될 경우 util-linux로 대체됨 

  • Poky에서 util-linux 부분 분석
  1. SRC_URI를 이용하여 BP 즉 Base Recipe 이름과 동일하게 Download
  2. PACKAGES =+ "${PN}-swaponoff"  , 이 util-linux-swaponoff는 나중에 추가
  3. PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pylibmount', '${PN}-pylibmount', '', d)}"  는 util-linux-pylibmount  미리 추가 
  4. PACKAGE_PREPROCESS_FUNCS =+ "util_linux_binpackages "   python 함수 사용
  5. PACKAGESPLITFUNCS =+ "util_linux_libpackages"  python 함수 사용
  6. python 함수를 분석을 해봐도 PACKAGE는 두개만 사용함 

  • util_linux_binpackages 의 pkg_hook 함수 분석
  1. PACKAGE들을 읽어서 RRECOMMENDS_ 추가 (PACKAGE의 종속성문제)
  2. ALTERNATIVE_PN 가 존재하면 return 종료
  3. ALTERNATIVE_LINK_NAME 이 module 과 동일하면 ALTERNATIVE_PN 설정
    
  • util_linux_binpackages (말그대로 util-linux package 관리)
이상한 것은 PACKAGES 와 do_split_packages로 구분관리하는것이 조금 이상하지만, 일단 이해만 하도록하자. 
.....
// 아래부터 시작되며, PACKAGES 대신 직접 함수로 Package 관리 
    bindirs = sorted(list(set(d.expand("${base_sbindir} ${base_bindir} ${sbindir} ${bindir}").split())))
    for dir in bindirs:
        do_split_packages(d, root=dir,
                          file_regex=r'(.*)', output_pattern='${PN}-%s',
                          description='${PN} %s',
                          hook=pkg_hook, extra_depends='')
    .......

  1. do_split_packages 함수 이용하여 PACKAGE관리하며, 매번 pkg_hook 호출 
  2. 중략
  3. 결론적으로 ALTERNATIVE를 비롯하여 FILE을 자동관리


추가시 busybox 대신 util-linux 용 package가 변경됨

댓글 없음 :
Tags: , ,
피드 구독하기: 덧글 ( Atom )