1. 프로젝트 단계
스펙 검토 → 브링업 → 시스템 안정화(버그수정)
2. 스펙 검토
2.1 하드웨어 부품 검토
* 제품의 특징에 따라 부품 선정
* 가격 경쟁력을 위해 부품 교체
2.2 소프트웨어 스펙 검토
* 리눅스 커널 버전
* 디바이스의 스펙을 맞출 수 있는지 검토
3. 브링업
* 한번도 부팅이 된 적이 없는 디바이스를 살리는 작업
* 시스템 소프트웨어 개발에서 가장 중요한 단계
* 여러 소프트웨어, 하드웨어 부품(칩, 메모리, 페리퍼럴)을 초기화하는 과정
3.1 브링업의 종류
* 소스 브링업
* 타겟 브링업 (보드 브링업, 페리퍼럴 브링업)
※ 보드에 전원을 켜면 자동으로 부팅이 된다 → 누군가가 보드 브링업을 진행한 상태
3.2 소스 브링업
* 새로운 SoC, 새로운 배포판 개발을 시작할 때
* 이 경우가 아니라면 소스 브링업은 건너뛴다.
* 일반적으로 보드 브링업을 하는 경우에는 소스 브링업을 하게 된다.
* Sequence
1. GIT을 활용해 SoC 벤더나 솔루션 업체로부터 소스를 받아옴
2. 컴파일러 설치 (시스템 속도를 더 올리기 위해서 컴파일러를 커스텀하는 경우가 있음)
3. 소스 빌드 (대부분은 명령어를 터미널에 입력하지 않고, 빌드 스크립트를 작성해서 실행하는 방식으로 빌드한다)
4. 빌드 아키텍처 분석
* 전체 이미지가 어떤 방식으로 생성되는지 체크
* 빌드 스크립트와 제품개발 관련 피쳐 및 컨피그 커스터마이즈
* 디바이스 트리 점검(리눅스 커널)
5. 이미지 다운로드 툴 분석
3.3 소스 브링업을 잘하기 위한 스킬
1. 욕토 빌드 시스템
* 사실상 빌드 프레임워크의 표준
* SoC벤더 대부분 욕토에 BSP 코드를 올려서 전달
2. GIT
3. 부트로더 및 리눅스 커널의 소스트리에 대한 이해
* 컴파일러 에러 수정 능력, Dependency 체크
4· Makefile에 대한 이해
* 컴파일러 옵션
* 소스 커스터마이제이션
* Shell Script
3.4 타겟 브링업
부팅 과정
전원 - 부트로더 - 리눅스 커널 - 드라이버
3.5 보드 브링업 과정에서 만나는 주요 이슈
1. 부트로더 크래시
* 부트로더 드라이버에서 크래시 발생
* 메모리나 전원을 초기화 하는 과정에서 문제
* 하드웨어성 이슈도 발생
2. 커널 패닉
* 디바이스 드라이버 설정 오류(디바이스 트리)
* 하드웨어(그래픽, 디바이스, 센서) 속성 설정 오류
* 컨피그 옵션 설정 문제
3. 메모리 이슈
* 랜덤하게 페이지 폴트 발생
* Memory Management 관련 초기화 문제
* 메모리 속성 설정 문제(Secure/Noe-secure)
* 비트 플립
4. 파워 이슈
* 커널 드라이버의 power management 문제
* 스펙에 정해진 전원(Voltage) 공급
* 정확하지 않은 파워 시퀀스
* Arm 코어 Hang
3.6 페리퍼럴(Peripheral) 브링업
대부분 임베디드 개발자들이 진행하는 브링업
1. 센서, 터치
* 인터럽트 설정
* 데이터 시트에 맞게 속성 설정
2. 카메라
* 인터페이스 점검(I2C, SPI)
* 데이터 시트 및 스펙 점검
3.7 페리퍼럴 브링업 과정에서 알아야 할 프로세스
1. 외부 벤더 업체와 커뮤니케이션
2. Reference 코드 리뷰
* 코드 전체 이해
* 디버깅 피쳐 면밀하게 점검
3.8 브링업을 잘하기 위해
1. 디버깅
* TRACE32
* UART 콘솔
* 주요 디버깅 피쳐 사용
2. 핵심 역량
* 리눅스 커널
* Arm 아키텍쳐
* SoC 아키텍쳐
* 디바이스 데이터 시트 리뷰
3. 커뮤니케이션
* 이슈를 있는 그대로 공유
* 도움 요청 - 브링업은 프로젝트 전체의 일정에 영향을 주기 때문에, 그때그때 이슈 공유가 필요하다.
4. 시스템 안정화
* 브링업과 기능 구현이 마무리되면 실행
* 다양한 스트레스 테스트 진행
* 테스트 도중 이슈가 나오면 시스템 소프트웨어 개발자에게 할당
4.1 버그 종류
크래시, 리셋
* 성능 이슈 : 시스템 느려짐, 화면 깨짐
* 기능 동작 : 스펙에 맞게 동작 못함
4.2 커널 크래시
커널 크래시에 대한 다양한 생각
1. 커널 크래시는 절대 발생하지 않는다. 리눅스 커널은 안정된 운영체제이다.
2. 디바이스 설정을 제대로 못해서 커널 크래시가 발생한다.
3. 커널 크래시는 하드웨어적인 문제로 인해 발생한다.
4. 커널 크래시가 발생하면 심각한 오류가 있는 상태이다.
커널 크래시에 대한 잘못된 Attitude
1. 리눅스 커널은 안정화된 코드고 검증됐기 때문에 커널 크래시가 발생할 리 없다.
2. 커널 크래시가 발생하면 SoC 개발자에게 던져라.
3. SoC벤더 개발자(퀄컴, 인텔, 엔비디아) 들이 LTS 리눅스 커널을 관리한다.
커널 크러시의 대표적인 유형들
1. 논리적인 오류
* Bug, Panic
* Fault, Exception
* Watchdog Reset : 소프트웨어가 정상적으로 동작하는지 확인하는 타이머
* Race Condition
2. 하드웨어 문제
* 메모리 비트 플립
* 전원 불안정
* 클락/파워 게이팅
* 프로세서 내 버그 - 한두달 동안 야근을 하게 될 수도 있다.
※ 새로운 칩셋, 플랫폼, 배포판, 최신 소프트웨어 구조에서 버그의 난이도가 높다.
※ 반대로 이미 검증됐거나 사용된 칩셋, 플랫폼에서 버그의 난이도가 높지 않음.
도전적인 프로젝트를 해야하는 이유
* 개발 역량 업그레이드
* 도전적인 프로젝트를 할 수 있는 기회는 자주 오지 않는다.
4.3 버그 해결 과정
1. 이슈 재현
* 문제 증상을 직접 확인
* 로그나 메모리덤프 추출
* Q/A 인증팀에서 받은 로그나 덤프 활용
2. 디버깅으로 원인 분석
* 로그나 덤프 분석
* 문제의 원인을 정확히 파악
* 디버깅 능력 요구
3. 패치 생성 및 담당자 이관
* 버그를 수정하기 위한 패치 생성
* 자신의 이슈가 아닌 경우 담당자에게 이관
* 하드웨어성 문제인 경우 하드웨어 개발자에게 이슈 설명
4. 테스트 진행 후 패치가 유효(Valid) 한지 검증
* 재현 경로로 테스트 진행
* 테스트를 통해 패치가 유효한지 검증
* 사이드 이펙트 유의
'JIRA : : Agile > : : Development Process' 카테고리의 다른 글
| [펌글] 임베디드 개발자 양극화는 얼마나 심각할까 + a (0) | 2024.05.13 |
|---|