[16 x 5 = ? ] 날자~~ 까마귀75

TinyML 낙서장

까마귀75 — Fri, 14 Jul 2023 14:40:37 +0900

TinyML 정의

TinyML은 에너지 비용이 1mW 미만인 하드웨어 플랫폼으로 정의할 수 있다. 즉 TinyML을 이해하려면 임베디드 장치를 이해해야 한다.

TinyML 적용가능 하드웨어

머신러닝이란?

무언가를 만들기 위해 모든 이론을 꼭 알아야 하는 것은 아니다. 결국 머신 러닝은 시행 착오가 전부이다.

머신러닝 알고리즘은 훈련(training)이라는 과정을 통해 알고리즘에 제공한 데이터를 기반으로 시스템의 모델(model)을 구축한다. 모델은 프로그램의 한 유형이다. 모델이 완성되면 여기에 새로운 데이터를 공급하여 예측을 수행하는데 이 과정을 추론(inference)이라 부른다.

머신러닝에는 여러 접근 방식이 있다. 딥러닝은 가장 인기 있는 접근 방식이다. 딥러닝은 인간의 뇌가 작동하는 방식에 대한 간단한 개념을 기반으로 한다. 딥러닝에서 시뮬레이션한 뉴런의 네트워크는 다양한 입력과 출력 간의 관계를 모델링하도록 훈련된다. 시물레이션된 뉴런의 배열을 아키텍처(architecture)라 하며 다양한 문제에 특화된 다양한 아키텍처가 있다.

머신러닝으로 문제를 해결하는 방식은 적절한 목표를 결정하고 적절한 데이터를 수집하고 레이블을 지정하고 모델에 전달할 특징을 설계하고 모델 아키텍처를 결정하는 과정을 반복하는 것이다. 적절한 모델이 나타날 때까지 반복하게 된다.

딥러닝 워크플로

목표 결정
수집할 데이터와 사용할 모델 아키텍처를 결정하려면 먼저 예측할 대상을 결정해야 한다.
데이터셋 수집
데이터 선택 : 문제 해결과 관련된 정보만 사용하여 모델을 훈련하는 것이 가장 좋다. 데이터 포함 여부를 결정할 때는 항상 도메인 전문 지식을 실험에 반영해야 한다. 특정 데이터 소스를 포함시킬지 확실하지 않다면 두 가지 모델(특정 데이터를 포함한 것과 안한 것)을 훈련시키고 그중 가장 적합한 모델을 선택하는 것도 좋은 방법이다.
데이터 수집 : 효과적인 모델을 훈련시키는 데 데이터가 얼마나 필요한지 정확히 알기는 어렵다(하지만 데이터는 많을 수록 좋다). 발생할 수 있는 모든 조건과 이벤트를 나타내는 데이터를 수집해야 한다. 다양성은 모델이 선택한 몇 가지 시나리오가 아니라 가능한 모든 시나리오를 나타내는 데 도움이 된다.
데이터 레이블링 : 수집한 데이터에 대한 클래스를 결정해야 한다. 데이터를 클래스와 연관시키는 과정을 레이블링(labeling)이라 한다. 모델이 입력을 분류하는 방법을 배울 수 있도록 훈련 과정에서 이 정보를 제공해야 한다. 데이터에 레이블을 지정하는 방법을 결정하면 이를 데이터셋에 추가할 수 있다.
최종 데이터셋
모델 아키텍처 설계
딥러닝 모델 아키텍처는 다양한 종류가 있으며 현존하는 아키텍처는 넓은 범위의 문제를 해결할 수 있다. 모델을 훈련할 때 고유한 아키텍처로 설계할 수도 있고 기존에 개발한 아키텍처를 기반으로 모델을 선택할 수 있다.
아키텍처를 결정할 때는 해결하려는 문제의 유형, 접근할 수 있는 데이터 유형, 데이터를 모델에 공급하기 전에 해당 데이터를 변환할 수 있는 방법을 고려해야 한다.
모델을 실행할 장치의 제약 조건도 고려해야 한다(마이크로 컨트롤러는 메모리가 제한적이고 프로세서 속도가 느리다).
TinyML에는 몇 개의 뉴련 층으로 간단한 모델을 훈련한 다음 유용한 결과를 얻을 때가지 반복적인 프로세스로 아키텍처를 개선하는 방법을 적용할 수 있다.
딥러닝 모델은 텐서 형태로 입력을 받고 출력을 생성한다.
벡터 : 배열과 비슷한 숫자 목록
행렬 : 2D 배열과 유사한 2D 텐서
고차원 텐서 : 3D 이상의 모든 형태 (그냥 텐서라고 불림)
스칼라 : 하나의 숫자 (0D 텐서)
정규화(normalization) : 네트워크에 전달하려는 값이 모두 비슷한 범위에 있도록 하는 작업 (0에 가까워지도록 축소)
일반화(regularization) : 딥러인 모델이 과적합에 빠질 가능성을 줄이기 위해 사용하는 기법 (훈련 중에 제공되는 데이터를 완벽하게 기억하지 못하도록 모델을 제한)
데이터 증식 : 훈련 데이터셋의 크기를 인위적으로 확장하는 방법 (훈련 데이터 전체에 일부 변형을 가한 여러 추가 버전을 만드는 과정)
모델 훈련
훈련은 모델이 주어진 입력 세트로 올바른 출력을 생성하는 방법을 배우는 과정이다. 트레이닝 데이터를 모델에 제공하여 가장 정확한 예측이 가능해질 때까지 조금식 조정하는 과정이다.
모델이란 시뮬레이션된 뉴런의 네트워크이다. 여러 레이어의 숫자 배열로 표현된다(이들 숫자를 가중치, 편향 또는 네트워크 파라미터라고 함).
모델 출력의 결과는 데이터를 네트워크에 공급하여 레이어의 가중치와 편향을 포함하는 연속적인 수학적 연산에 의해 변환된 값이다.
모델이 정확한 예측을 하기 시작한 시점부터는 모델이 수렴했다고 표현한다. 모델이 수렴됐는지 확인하는 일반적인 성능 지표는 손실과 정확도이다.
모델 성능을 개선하기 위해 모델의 아키텍처를 변경하고 훈련 과정을 조정하는 데 사용하는 다양한 값을 하이퍼파라미터라고 한다.
해결하려는 문제에 대해 충분한 정확도를 달성할 수 있다는 보장은 없으며, 100% 정확하지 않더라도 유용할 수 있다.
모델이 수렴하지 못하는 가정 일반적인 이유는 과적합과 과소적합 때문이다. 모델이 적합하면 주어진 입력 세트에 대해 올바른 출력을 생성한다.
과소적합이란 충분한 패턴을 학습하지 못하여 좋은 예측을 할 수 없는 상태를 의미한다(일반적으로 아키텍처가 너무 작아 모델링해야 하는 시스템의 복잡성을 포착하기에 충분하지 않거나 충분한 데이터로 학습을 못했기 때문이다).
과적합이한 훈련 데이터를 너무 잘 배웠다는 의미이다(훈련 데이터에 대해서는 정확한 출력을 예측할 수 있지만 처음 보는 데이터까지 예측할 수 있는 일반화된 모델로 작동할 수 없다).
모델 변환
텐서플로 모델은 출력을 생성하기 위해 인터프리터에 데이터를 변환하는 방법을 알려주는 일련의 명령어이다. 모델을 메모리에 로드하고 텐서플로 인터프리터를 사용하여 실행하면 모델을 사용할 수 있다.
텐서플로 인터프리터는 데스크톱 컴퓨터와 서버에서 모델을 실행하도록 설계되어 있다.
텐서플로 라이트는 소형 저전력 장치에서 모델을 실행하기 위한 인터프리터와 도구를 제공한다.
텐서플로 라이트에서 모델을 실행하려면 모델을 텐서플로 라이트 컨버터를 사용하여 텐서플로 라이트 형식으로 변환한 다음 디스크에 파일로 저장해야 한다. 텐서플로 라이트 컨버터는 모델의 크기를 줄이고 성능 저하 없이 빠르게 실행하기 위한 최적화 기능을 제공한다.
추론 실행
마이크로 컨트롤러용 텐서플로 라이트 C++ 라이브러리를 사용하여 모델을 로드하고 예측을 수행한다.
모델이 애플리케이션 코드와 결합하기 때문에 원시 입력 데이터를 훈련 데이터와 동일한 형식으로 변환하는 코드를 작성해야 한다. 그런 다음 변환된 데이터를 모델로 전달하여 추론을 실행한다.
모델은 추론을 통해 예측을 포함하는 출력 데이터를 생성한다.
평가 및 문제 해결
모델을 배포하고 실행한 후 실제 성능이 원하는 결과에 근접하는지 확인할 수 있다. 모델이 테스트 데이터에서 정확하게 예측한다는 사실은 입증했지만 실제 환경에서의 성능은 다를 수 있다.
모델이 실제 환경에서 잘 작동하지 않는다면 문제 해결을 수행해야 한다. 환경적인 문제인지 과적합 문제인지 판단하여 문제를 해결한다.

모델 구축과 훈련

머신러닝 도구

파이썬과 주피터 노트북

파이썬은 머신러닝 과학자와 엔지니어가 선호하는 프로그래밍 언어이다. 수학과 관련된 수 많은 라이브러리가 존재한다.

파이썬은 주피터 노트북과 함께 사용하면 좋다. 주피터 노트북은 클릭 한 번으로 문서 작업, 그래픽, 코드를 함께 실행할 수 있는 특수 문서 형식이다. 주피터 노트북은 머신러닝 코드와 문제를 설명하고 탐색하는 도구로 널리 사용된다.

구글 코랩

구글 코랩은 주피터 노트북을 실행하기 위한 온라인 환경을 제공하며 머신러닝 연구 개발을 장려하는 구글에서 만든 무료 도구이다(일정 부분 무료).

주피터 노트북 환경을 만들어 사용하게 되면, 파이썬 라이브러리와 같은 많은 종속성을 직접 설치하여 사용하므로 다른 버전의 종속성을 갖는 라이브러리가 있을 수 있어 다른 사람과 공유하기 어렵고 예상대로 실행되지 않기도 했다.

구글 코랩을 사용하면 구글의 하드웨어에서 무료로 노트북을 실행할 수 있고 다른 사람들과 공유하여 동일한 결과를 얻을 수 있다.

텐서플로와 케라스

텐서플로는 머신러닝 모델을 구축, 훈련, 평가, 배포하기 위해 구글에서 개발한 오픈소스 프로젝트이며 머신러닝에 가장 널리 사용되는 프레임워크이다. 개발자는 대부분 파이썬 라이브러리 형태로 텐서플로를 사용한다.

케라스는 딥러닝 네트워크를 쉽게 구축하고 훈련시킬 수 있는 텐서플로의 고급 API이다.

텐서플로 라이트는 텐서플로 모델을 모바일과 임베디드 장치에 배포하는 도구 세트이다.

모델 구축과 훈련

"모델 구축과 훈련"과 관련하여 Colab에서 검증한 노트북의 Github 링크로 대체한다. 해당 링크에서 "first_sine_model.ipynb" 파일을 참조한다. 책에 나오는 예제를 Colab에서 직접 따라해 보면서 작성한 노트북이다.

해당 노트북을 끝가지 진행하면 TensorFlow Lite Converter로 변환한 모델 소스 파일을 얻을 수 있다. 이 파일을 사용하여 마이크로 컨트롤러에서 직접 TensorFlow Lite를 구동할 것이다.

애플리케이션 구축

모델은 머신러닝 애플리케이션의 일부일 뿐이다. 모델 자체로는 아무것도 할 수 없는 정보의 덩어리이다.

모델을 사용하려면 모델을 실행하는 데 필요한 환경을 설정하고 입력을 제공하고 출력을 사용하여 동작을 생성하는 코드로 모델을 랩핑해야 한다.

기본적인 TinyML 애플리케이션 아키텍처 흐름은 다음과 같다.

입력 데이터
전처리 : 모델에 적합하게 입력을 변환
TensorFlow Lite 인터프리터 : 데이터를 바탕으로 예측하도록 훈련된 신경망 모델을 실행
후처리 : 모델의 출력을 해석하고 판단
출력 처리 : 디바이스의 리소스를 사용하여 예측에 따른 반응 수행

실제 애플리케이션 코드 작업 전에 테스트를 먼저 작성한다. 테스트를 실행하여 예상대로 작동하는 것을 검증할 수 있다.

아래 코드는 hello_world 예제의 테스트 코드이다. 코드 설명은 주석으로 대신한다.

//	아파치 2.0 오픈소스 라이선스 정보이다.
/* Copyright 2019 The TensorFlow Authors. All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
==============================================================================*/

// #include "tensorflow/lite/c/common.h"
// xxd를 사용하여 C 코드로 변환한 sine 모델
#include "tensorflow/lite/micro/examples/hello_world/sine_model_data.h"
// 인터프리터가 모델에서 사용하는 
// Op(TensorFlow Operation 약자. 계산을 수행하는 핵심 노드를 의미)를
// 로드할 수 있게 하는 클래스
#include "tensorflow/lite/micro/kernels/all_ops_resolver.h"
// 디버깅을 위해 오류와 출력을 기록하는 클래스
#include "tensorflow/lite/micro/micro_error_reporter.h"
// 모델을 실행할 마이크로 컨트롤러용 TensorFlow Lite 인터프리터
#include "tensorflow/lite/micro/micro_interpreter.h"
// 테스트 작성을 위한 간단한 프레임워크. 실제 테스트를 실행
#include "tensorflow/lite/micro/testing/micro_test.h"
// sine_model_data.h의 모델 데이터를 분석하는 데 사용되는
// 텐서플로 라이트 플랫버퍼 데이터 구조를 정의하는 스키마
#include "tensorflow/lite/schema/schema_generated.h"
// 스키마의 현재 버전. 모델이 호한 가능한 버전으로 정의되어 있는지 확인
#include "tensorflow/lite/version.h"

// micro_test.h에 정의된 매크로. 테스트 시작
TF_LITE_MICRO_TESTS_BEGIN

// micro_test.h에 정의된 매크로. 테스트 수행 코드
TF_LITE_MICRO_TEST(LoadModelAndPerformInference) {
  // 디버그 정보 출력 메커니즘 설정
  // MicroErrorReporter 인스턴스 생성(/micro_error_reporter.h 정의).
  // 추론 중에 디버그 정보를 기록하는 메커니즘을 제공.
  tflite::MicroErrorReporter micro_error_reporter;
  // MicroErrorReporter의 인스턴스를 ErrorReporter에 설정
  tflite::ErrorReporter* error_reporter = &micro_error_reporter;

  // 사용 가능한 데이터 구조에 모델을 매핑한다.
  // 복사나 파싱을 포함하지 않는 가벼운 작업이다.
  // g_sine_model_data는 sine_model_data.h에 정의되어 있다.
  // Model은 schema_generated.h에 정의되어 있고 모델 데이터를 담는 구조체이다.
  const tflite::Model* model = ::tflite::GetModel(g_sine_model_data);
  // 모델의 버전 번호를 TensorFlow Lite 스키마 버전과 비교한다.
  if (model->version() != TFLITE_SCHEMA_VERSION) {
  	// 버전 번호가 맞지 않으면 메세지를 기록한다.
    TF_LITE_REPORT_ERROR(error_reporter,
                         "Model provided is schema version %d not equal "
                         "to supported version %d.\n",
                         model->version(), TFLITE_SCHEMA_VERSION);
  }

  // 필요한 모든 Op(operation) 구현을 가져온다.
  // all_ops_resolver.h에 정의됨.
  // 마이크로 컨트롤러용 TensorFlow Lite 인터프리터가 Op에 접근할 수 있도록 한다.
  tflite::ops::micro::AllOpsResolver resolver;

  // 모델의 입력, 출력, 중간 텐서 배열에 사용할 메모리 영역을 생성한다.
  // 이 영역을 텐서 아레나(tensor arena)라고 부른다.
  // 사용하는 모델에서 최소값을 찾으려면, 시행착오가 필요하다.
  const int tensor_arena_size = 2 * 1024;
  uint8_t tensor_arena[tensor_arena_size];

  // 모델을 실행하기 위한 인터프리터를 빌드한다.
  tflite::MicroInterpreter interpreter(model, resolver, tensor_arena,
                                       tensor_arena_size, error_reporter);

  // 모델에서 사용하는 텐서에 대해 tensor_arena의 메모리를 할당
  TF_LITE_MICRO_EXPECT_EQ(interpreter.AllocateTensors(), kTfLiteOk);

  // 모델의 입력 텐서에 대한 포인터 획득
  // 여기서는 입력이 하나이므로 인덱스는 0으로 설정
  // c_api_internal.h에 정의
  TfLiteTensor* input = interpreter.input(0);

  // TF_LITE_MICRO_EXPECT_NE와 TF_LITE_MICRO_EXPECT_EQ는 테스트 프레임워크의 매크로이다.
  // 변수 값에 대한 assertion 코드이다.
  // 입력 텐서가 존재하는지 확인(NE = Not Equal)
  TF_LITE_MICRO_EXPECT_NE(nullptr, input);
  // 속성 "dims"는 텐서의 모양을 나타낸다. 각 차원의 원소는 하나이다.
  // 입력은 한 개의 원소를 포함하는 2D 텐서이므로 "dims"의 크기는 2이다.
  // (EQ = Equal)
  TF_LITE_MICRO_EXPECT_EQ(2, input->dims->size);
  // 각 원소의 값은 해당 텐서의 길이를 나타낸다.
  // 두 개의 단일 원소 텐서(하나가 다른 하나에 포함)를 갖는지 확인한다.
  TF_LITE_MICRO_EXPECT_EQ(1, input->dims->data[0]);
  TF_LITE_MICRO_EXPECT_EQ(1, input->dims->data[1]);
  // 입력은 32비트 부동소수점 값이다.
  TF_LITE_MICRO_EXPECT_EQ(kTfLiteFloat32, input->type);

  // 입력 값을 제공한다.
  // data 변수는 TfLitePtrUnion(c_api_internal.h 정의)이다.
  input->data.f[0] = 0.;

  // 입력 값으로 모델을 실행하고 성공 여부를 검사한다.
  TfLiteStatus invoke_status = interpreter.Invoke();
  if (invoke_status != kTfLiteOk) {
  	error_reporter->Report("Invoke failed\n");
  }
  TF_LITE_MICRO_EXPECT_EQ(kTfLiteOk, invoke_status);

  // 출력 텐서의 포인터를 획득하여 예상하는 속성을 가지고 있는지 확인한다.
  // 입력 텐서와 동일한 속성이다.
  TfLiteTensor* output = interpreter.output(0);
  TF_LITE_MICRO_EXPECT_EQ(2, output->dims->size);
  TF_LITE_MICRO_EXPECT_EQ(1, input->dims->data[0]);
  TF_LITE_MICRO_EXPECT_EQ(1, input->dims->data[1]);
  TF_LITE_MICRO_EXPECT_EQ(kTfLiteFloat32, output->type);

  // 텐서의 출력 값을 가져온다.
  float value = output->data.f[0];
  // 출력 값과 예상 값의 차이가 0.5 범위에 있는지 확인한다.
  TF_LITE_MICRO_EXPECT_NEAR(0., value, 0.05);

  // 몇 가지 값의 추론을 더 실행하여 예상하는 출력을 확인한다.
  // interpreter.input(0)와 interpreter.output(0)을 다시 호출할 필요가 없다.
  input->data.f[0] = 1.;
  invoke_status = interpreter.Invoke();
  TF_LITE_MICRO_EXPECT_EQ(kTfLiteOk, invoke_status);

  value = output->data.f[0];
  TF_LITE_MICRO_EXPECT_NEAR(0.841, value, 0.05);

  input->data.f[0] = 3.;
  invoke_status = interpreter.Invoke();
  TF_LITE_MICRO_EXPECT_EQ(kTfLiteOk, invoke_status);

  value = output->data.f[0];
  TF_LITE_MICRO_EXPECT_NEAR(0.141, value, 0.05);

  input->data.f[0] = 5.;
  invoke_status = interpreter.Invoke();
  TF_LITE_MICRO_EXPECT_EQ(kTfLiteOk, invoke_status);

  value = output->data.f[0];
  TF_LITE_MICRO_EXPECT_NEAR(-0.959, value, 0.05);
}

//	micro_test.h에 정의된 매크로. 테스트 종료
TF_LITE_MICRO_TESTS_END

실제 도서에서 제공되는 코드를 실행하는 절차는 아래와 같다(Ubuntu 20.04에서 실행함).

다운로드할 디렉터리를 생성하고, 생성한 디렉터리로 이동한다.
$ mkdir TinyML
$ cd TinyML
Github에서 소스를 다운로드하고 생성된 "tensorflow-lite" 디렉터리로 이동한다(도서에 있는 경로로 하면 실행이 안된다).
$ git clone https://github.com/yunho0130/tensorflow-lite.git
$ cd tensorflow-lite
make 커맨드를 아래와 같이 실행하여 테스트를 수행한다(처음 make 실행시 시간이 다소 소요됨).
$ make -f tensorflow/lite/micro/tools/make/Makefile test_hello_world_test

테스트를 실행하면 도서의 내용과 다르게 출력된다.

'~~~ALL TESTS PASSED~~~'
tensorflow/lite/micro/tools/make/gen/linux_x86_64/bin/hello_world_test: PASS

도서의 내용 처럼 인위적으로 실패하게 수정하면, 도서의 내용과 동일하게 출력된다.

Testing LoadModelAndPerformInference
0. (1.0*2^-127) near value (1.6142864*2^-1) failed at tensorflow/lite/micro/examples/hello_world/hello_world_test.cc:92
0/1 tests passed
~~~SOME TESTS FAILED~~~

hello_world 프로젝트 파일 구조

실제 마이크로 컨트롤러에서 사용할 hello_world 프로젝의 파일 구조를 살펴본다. 해당 프로젝트의 루트는 "tensorflow/lite/micro/examples/hello_world"에 있다.

BUILD : 테스트를 포함하여 애플리케이션의 소스 코드를 사용하여 빌드할 수 있는 다양한 항목을 나열하는 파일.
Makefile.inc : 테스트와 애플리케이션의 빌드 대상에 대한 정보가 포함된 Makefile(일부 소스 파일을 정의).
README.md : 애플리케이션 빌드와 실행에 대한 절차를 포함하는 텍스트 파일.
constants.h, constants.cc : 프로그램 동작을 정의하는 데 중요한 영향을 미치는 다양한 상수를 포함하는 파일 세트.
create_sine_model.ipynb : 신경망 모델을 만드는 주피터 노트북.
hello_world_test.cc : 생성한 신경망 모델을 사용하여 추론을 실행하는 테스트.
main.cc : 애플리케이션의 실행되는 프로그램 진입점.
main_functions.h, main_functions.cc : 프로그램에 필요한 모든 초기화를 수행하는 setup() 함수와 프로그램의 핵심 로직을 포함하고 상태 머신을 무한히 순환하게 설계된 loop() 함수를 정의하는 파일 세트. main.cc에 의해 호출.
output_handler.h, output_handler.cc : 추론을 실행될 때마다 출력을 표시하는 데 사용할 수 있는 함수를 정의하는 파일 세트. 기본 구현은 결과를 화면에 출력하고 이 구현을 재정의하여 다른 작업을 수행할 수 있다.
output_handler_test.cc : output_handler.h, output_handler.cc의 코드가 올바르게 작동하는지 검증하는 테스트.
sine_model_data.h, sine_model_data.cc : 생성된 신경망 모델의 데이터 배열을 정의하는 파일 세트.

마이크로컨트롤러마다 기능과 API가 다르기 때문에 특정 디바이스용으로 빌드하는 경우 프로젝트 구조를 통해 특정 디바이스의 소스 파일을 제공할 수 있다. 아래의 디렉러리는 특정 디바이스에서 제공하는 소스 파일을 포함한다.

/arduino
/disco_f746ng
/esp
/sparkfun_edge

소스 코드 분석

main_functions.cc 파일 코드 분석 (설명은 코드 주석으로 대신한다.)

//	아파치 2.0 오픈소스 라이선스 정보이다.
/* Copyright 2019 The TensorFlow Authors. All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
==============================================================================*/
// 소스에서 사용하는 헤더 파일을 정의한다.
#include "tensorflow/lite/micro/examples/hello_world/main_functions.h"

#include "tensorflow/lite/micro/examples/hello_world/constants.h"
#include "tensorflow/lite/micro/examples/hello_world/output_handler.h"
#include "tensorflow/lite/micro/examples/hello_world/sine_model_data.h"
#include "tensorflow/lite/micro/kernels/all_ops_resolver.h"
#include "tensorflow/lite/micro/micro_error_reporter.h"
#include "tensorflow/lite/micro/micro_interpreter.h"
#include "tensorflow/lite/schema/schema_generated.h"
#include "tensorflow/lite/version.h"

// 아두이노 스타일과 호환성을 위해 사용한다.
// 소스 파일내에서 사용할 전역 변수를 정의한다.
// 네임스페이스로 묶어서 소스내에서는 접근할 수 있지만,
// 프로젝트 내의 다른 파일에서는 접근할 수 없다.
// 동일한 변수를 서로 다른 파일에서 정의할 때 생기는 문제를 방지할 수 있다.
namespace {
// 아래 변수는 테스트 코드 작성에서 정의한 변수와 동일.
tflite::ErrorReporter* error_reporter = nullptr;
const tflite::Model* model = nullptr;
tflite::MicroInterpreter* interpreter = nullptr;
TfLiteTensor* input = nullptr;
TfLiteTensor* output = nullptr;
// 추론을 실행한 횟수를 기록
int inference_count = 0;

// 입력, 출력, 중간 배열에 사용할 메모리 영역을 생성한다.
// 신경망 모델의 최솟값을 찾으려면 시행착오가 필요하다.
constexpr int kTensorArenaSize = 2 * 1024;
uint8_t tensor_arena[kTensorArenaSize];
}  // namespace

// 함수의 이름은 아두이노와 호환을 위해 중요하다.
// 프로그램이 처음 실행될 때 한번만 호출된다.
// 추론을 시작하기 전에 수행해야 할 일회성 작업을 수행한다.
void setup() {
  // 로깅 설정. Google 스타일은 수명 불확실성 때문에 전역이나 정적을 피하지만,
  // 사소한 소멸자가 있어 상관없다.
  // NOLINTNEXTLINE(runtime-global-variables)
  static tflite::MicroErrorReporter micro_error_reporter;
  error_reporter = &micro_error_reporter;

  // 모델을 사용할 데이터 구조체에 매핑한다.
  // 이는 복사나 파싱을 포함하지 않는 매우 가벼운 작업이다.
  model = tflite::GetModel(g_sine_model_data);
  if (model->version() != TFLITE_SCHEMA_VERSION) {
    TF_LITE_REPORT_ERROR(error_reporter,
                         "Model provided is schema version %d not equal "
                         "to supported version %d.",
                         model->version(), TFLITE_SCHEMA_VERSION);
    return;
  }

  // 필요한 모든 오퍼레이션 구현을 가져온다.
  // NOLINTNEXTLINE(runtime-global-variables)
  static tflite::ops::micro::AllOpsResolver resolver;

  // 모델을 실행할 인터프리터를 빌드한다.
  static tflite::MicroInterpreter static_interpreter(
      model, resolver, tensor_arena, kTensorArenaSize, error_reporter);
  interpreter = &static_interpreter;

  // 모델의 텐서를 tensor_arena로부터 메모리 할당한다.
  TfLiteStatus allocate_status = interpreter->AllocateTensors();
  if (allocate_status != kTfLiteOk) {
    TF_LITE_REPORT_ERROR(error_reporter, "AllocateTensors() failed");
    return;
  }

  // 모델의 입력/출력 텐서에 대한 포인터를 가져온다.
  // TfLiteTensor라는 구조체가 가진 data 멤버는 출력을 저장하기 위한
  // 할당된 메모리 영역을 가리킨다. 출력이 없더라고 data 메모리 영역은 존재한다.
  input = interpreter->input(0);
  output = interpreter->output(0);

  // 추론을 실행한 횟수를 기록하기 위한 변수 초기화
  inference_count = 0;
}

// 함수의 이름은 아두이노와 호환을 중요하다.
// 계속 반복되는 실행 코드가 위치한다.
void loop() {
  // 모델에 전달할 x 값을 계산한다.
  // 현재 inference_count를 주기당 추론 횟수와 비교하여
  // 모델이 학습된 지정 가능한 x 값 범위 내에서 위치를 결정하고
  // 이를 사용하여 값을 계산한다.
  // kXrange, kInferencesPerCycle 상수는 constants.h, constants.cc에 정의
  float position = static_cast<float>(inference_count) /
                   static_cast<float>(kInferencesPerCycle);
  float x_val = position * kXrange;

  // 계산된 x 값을 모델의 입력 텐서에 넣는다.
  input->data.f[0] = x_val;

  // 추론을 실행하고 에러를 리포트한다.
  TfLiteStatus invoke_status = interpreter->Invoke();
  if (invoke_status != kTfLiteOk) {
    TF_LITE_REPORT_ERROR(error_reporter, "Invoke failed on x_val: %f\n",
                         static_cast<double>(x_val));
    return;
  }

  // 모델의 출력 텐서에서 예측된 y 값을 읽는다.
  float y_val = output->data.f[0];

  // 결과를 출력한다. 사용자 지정 HandleOutput 함수는 
  // 지원되는 하드웨어 장비에 대해 구현될 수 있다.
  HandleOutput(error_reporter, x_val, y_val);

  // inference_counter를 증가시키고
  // 주기당 최대 추론 수에 도달하면 재설정한다.
  inference_count += 1;
  if (inference_count >= kInferencesPerCycle) inference_count = 0;
}

main_functions.cc 파일의 setup(), loop() 함수는 main.cc에서 호출한다.

main.cc 파일 코드 분석 (설명은 코드 주석으로 대신한다.)

//	아파치 2.0 오픈소스 라이선스 정보이다.
/* Copyright 2019 The TensorFlow Authors. All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
==============================================================================*/
// setup(), loop() 함수가 정의된 헤더 파일을 포함한다.
#include "tensorflow/lite/micro/examples/hello_world/main_functions.h"

// 이 함수는 표준 C 엔트리 포인트를 가지는 시스템에서 사용되는 기본 main이다.
// 엔트리 코드에 대해 다른 요구 사항(app_main 함수와 같은)을 가지는 다른 디바이스
// (예로 FreeRTOS나 ESP32)는 대상별 하위 폴더에서 main.cc 파일을 특수화해야 한다.
int main(int argc, char* argv[]) {  
  setup();
  while (true) {
    loop();
  }
}

호스트에서 애플리케이션 실행

애플리케이션에서 실행하려면 빌드를 진행해야 한다. 아래는 리눅스에서 make 명령을 사용하여 실행 가능한 바이너리를 생성하는 방법이다.

$ make -f tensorflow/lite/micro/tools/make/Makefile hello_world

빌드가 완료되면 아래와 같이 바이너리를 실행할 수 있다.

$ ./tensorflow/lite/micro/tools/make/gen/linux_x86_64/bin/hello_world

바이너리가 실행되면 아래와 같이 출력된다.

x_value: 1.2566366*2^-1, y_value: 1.1161486*2^-1
x_value: 1.8849551*2^-1, y_value: 1.5661856*2^-1
x_value: 1.2566366*2^0, y_value: 1.8288908*2^-1
x_value: 1.5707957*2^0, y_value: 1.9224764*2^-1
x_value: 1.8849551*2^0, y_value: 1.8043818*2^-1
x_value: 1.995567*2^1, y_value: 1.5224055*2^-1
x_value: 1.2566366*2^1, y_value: 1.1094988*2^-1
...

애플리케이션을 종료하려면 "Ctrl + c"를 입력한다.

마이크로 컨트롤러에 배포

여기서는 ~~STM32H750 디스커버리 키트~~에 배포하는 절차를 설명한다(도서에서 설명하는 보드가 없는 관계로...).

※ STM32H750 디스커버리 키트는 내부 플래시 용량(128KBytes) 문제로 실행할 수 없다. DISCO_F746NG를 사용하는 mbed 환경 설정과 컴파일 과정만 정리한다.

마이크로 컨트롤러란?

실제 마이크로 컨트롤러는 회로 기판(PCB)에 부착된 많은 전자 부품 중 하나이다. 마이크로 컨트롤러는 핀으로 회로 기판에 연결된다. 일반적인 마이크로 컨트롤러는 수십 개의 핀이 있으며 모두 용도가 다르다. 어떤 핀은 전원을 공급하고 어떤 핀은 다른 중요한 부품과 연결된다. 마이크로 컨트롤러에서 실행되는 프로그램에 의해 디비털 신호의 입력과 출력을 수행하는 핀을 GPIO(General Purpose Input/Output) 핀이라 한다. GPIO 핀이 입력으로 동작하면 전압이 외부에서 들어오는지 검사할 수 있고, 출력으로 동작하면 전압을 외부로 공급하게 된다. GPIO 핀은 디지털이므로 출력 모드에서 스위치처럼 ON/OFF 동작을 한다. 입력 모드에서는 전압이 특정 임계값보다 높거나 낮은지 검사할 수 있다. 아날로그 입력 핀이 있는 일부 마이크로 컨트롤러는 정확한 입력 값을 측정할 수 있다.

DISCO_F746NG용 MBED 환경 설정 및 컴파일

Ubuntu 20.04에서 환경 설정 및 컴파일 방법을 설명한다. 도서에 자세히 설명되어 있으나, 몇 가지 수정 사항이 있다.

먼저 MBED CLI 환경 설정을 한다(참고 사이트).

Ubuntu에서 필요한 패키지를 설치한다.

$ sudo apt install python3 python3-pip git mercurial

Mbed CLI를 설치하고 업데이트 한다.

$ python3 -m pip install mbed-cli

$ python3 -m pip install -U mbed-cli

컴파일러를 다운 받아서 적당한 위치에 압축을 푼다. 컴파일러는 링크에서 다운 받을 수 있다.

링크에서 gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2(2023/8/1 기준, 향후 업데이트 될 수 있음)를 다운 받아 압축을 푼다.

$ tar -xvf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2

Mbed CLI에서 컴파일러를 구성한다. 아래 명령어를 사용하여 "ARM_PATH"와 "GCC_ARM_PATH"를 설정한다.

$ mbed config -G ARM_PATH "<압축푼 위치>/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc"

$ mbed config -G GCC_ARM_PATH "<압축푼 위치>/gcc-arm-none-eabi-10.3-2021.10/bin"

GitHub에서 소스를 다운로드한다.

$ git clone https://github.com/yunho0130/tensorflow-lite.git

다운로드한 디렉터리로 이동한다.

$ cd tensorflow-lite

이후 도서에 나오는 내용대로 진행을 한다.

$ make -f tensorflow/lite/micro/tools/make/Makefile TARGET=mbed TAGS="cmsis disco_f746ng" generate_hello_world_mbed_project

도서에는 TAGS가 "CMSIS disco_f746ng"로 되어있으나, 이렇게 수행하면 make에서 에러가 난다. "CMSIS"를 소문자 "cmsis"로 변경하면 에러 없이 진행할 수 있다. github에서 "cmsis-nn"으로 하라고 되어 있으나, 나중에 컴파일시 에러가 발생한다(에러를 해결하려다 포기).

프로젝트가 생성된 디렉터리로 이동한다.

$ cd cd tensorflow/lite/micro/tools/make/gen/mbed_cortex-m4/prj/hello_world/mbed/

Mbed 프로젝트의 루트를 설정한다.

$ mbed config root .

Mbed 종속성을 다운로드한다.

$ mbed deploy

Mbed에서 사용할 컴파일러를 설정한다. 기본으로 C++98로 컴파일을 하는데 C++11로 변경한다.

$ python -c 'import fileinput, glob;
for filename in glob.glob("mbed-os/tools/profiles/*.json"):
    for line in fileinput.input(filename, inplace=True):
        print(line.replace("\"-std=gnu++98\"","\"-std=c++11\"-fpermissive\""))'

아래 명령을 사용하여 컴파일을 진행한다.

$ mbed compile -m DISCO_F746NG -t GCC_ARM

컴파일이 완료되면, 아래와 같은 내용을 볼 수 있다.

Link: mbed
Elf2Bin: mbed
| Module                              |           .text |       .data |          .bss |
|-------------------------------------|-----------------|-------------|---------------|
| BSP_DISCO_F746NG/Drivers            |     2400(+2400) |       1(+1) |     584(+584) |
| BSP_DISCO_F746NG/Utilities          |           0(+0) |       8(+8) |         0(+0) |
| LCD_DISCO_F746NG/LCD_DISCO_F746NG.o |       150(+150) |       0(+0) |         0(+0) |
| [fill]                              |       126(+126) |       7(+7) |       26(+26) |
| [lib]/c.a                           |   35640(+35640) | 2472(+2472) |       58(+58) |
| [lib]/gcc.a                         |     3448(+3448) |       0(+0) |         0(+0) |
| [lib]/m.a                           |     6216(+6216) |       0(+0) |         0(+0) |
| [lib]/misc                          |       188(+188) |       4(+4) |       28(+28) |
| [lib]/nosys.a                       |         32(+32) |       0(+0) |         0(+0) |
| [lib]/stdc++.a                      |         40(+40) |       0(+0) |       16(+16) |
| mbed-os/drivers                     |       872(+872) |       0(+0) |         0(+0) |
| mbed-os/hal                         |     1314(+1314) |       8(+8) |     130(+130) |
| mbed-os/platform                    |     4268(+4268) |   260(+260) |     240(+240) |
| mbed-os/targets                     |   12778(+12778) |       4(+4) |   1152(+1152) |
| tensorflow/lite                     |   77536(+77536) |       4(+4) |   8118(+8118) |
| Subtotals                           | 145008(+145008) | 2768(+2768) | 10352(+10352) |
Total Static RAM memory (data + bss): 13120(+13120) bytes
Total Flash memory (text + data): 147776(+147776) bytes

바이너리 크기가 140KBytes 정도가 나와서 DISCO_H750B에서는 돌릴 수가 없었다.

참고 사이트

사이트	설명
초소형 머신러닝 TinyML	TinyML 도서
https://github.com/tensorflow/tensorflow/tree/be4f6874533d78f662d9777b66abe3cdde98f901/tensorflow/lite/experimental/micro	TinyML 도서 오픈소스 Github 저장소
https://github.com/yunho0130/tensorflow-lite	TinyML 도서 오픈소스 Github 저장소
https://www.sparkfun.com/products/retired/15420	스파크펀 에지2 제조사
https://github.com/sparkfun/SparkFun_Edge	스파크펀 에지2 Github 저장소

i.MX 8M Plus 개발 환경 구축 - Yocto 사용자 정의

까마귀75 — Wed, 12 Jul 2023 10:06:59 +0900

[이전] [목차] [다음]

Yocto 사용자 정의

개발중 또는 제품화에서 필요한 Yocto 사용자 정의를 정리한다.

SD Card, EMMC의 ROOTFS 크기 조정

imx8mp-evk에서 "imx-image-full"로 이미지를 생성하면 대략 8GB의 rootfs 이미지가 만들어 진다.

이 경우 사용하려는 SD Card나 EMMC의 용량이 8GB 보다 크면, 8GB를 제외한 저장 공간이 사용되지 않는다.

SD Card나 EMMC의 저장 공간을 최대한 사용하려면 아래의 단계를 따른다.

"imx-image-full"을 사용하여 생성된 이미지를 SD Card나 EMMC에 플래싱(저장)한다.
보드를 부팅후 "df -h" 커맨드(크기에 따라 MB나 GB로 출력된다)를 사용하여 저장 공간을 확인한다.
Filesystem의 "/dev/root"의 저장 공간 크기를 확인한다. 이 크기가 실제 rootfs의 크기이다(기본으로 8GB 정도이다).
SD Card나 EMMC의 실제 저장 공간에서 위에서 확인한 크기를 제외한 사용되지 않는 저장 공간을 계산한다.
예로 SD Card나 EMMC가 16GB인 경우 8GB의 사용되지 않는 저장 공간이 있다.
사용되지 않는 공간보다 적은 크기의 추가 공간의 크기를 결정한다.
추가 공간의 크기는 KB 단위로 설정하게 되어 있다.

여기서는 5GB를 추가한다고 가정한다.

"<build-dir>/conf/local.conf" 파일에 아래 내용을 추가한다(<build-dir>은 빌드 디렉터리이다).

IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

"IMAGE_ROOTFS_EXTRA_SPACE"는 rootfs에 포함할 추가 용량을 나타낸다.

이미지를 다시 빌드하면, 5GB가 추가된 이미지가 생성된다(총 13GB의 rootfs 생성).

1GB는 "1048576"으로 계산된다.

"imx-linux-kirkstone" 이후에 생성된 이미지는 압축되어 있어서 이미지 저장시(플래싱) 시간을 단축할 수 있다.

이전에는 "wic" 확장자를 가진 이미지를 업데이트 했었는데, 이 이미지는 실제 rootfs의 크기와 동일하여 13GB의 이미지 생성시 실제로 파일 크기가 13GB가 생성이 되었다.

요즘은 "zst"로 압축된 이미지가 생성되어 실제 rootfs 크기보다 훨씬 적은 크기의 이미지가 생성이 된다.

21GB의 rootfs를 생성하면 실제 크기는 1.3GB 정도가 나온다.

아마 추가되는 크기는 모두 패팅으로 처리되는 것으로 보여진다.

아래는 "zst"로 생성된 이미지를 "dd" 커맨드를 이용하여 EMMC에 저장하는 커맨드이다.

zstdcat imx-image-full.rootfs.wic.zst | dd of=/dev/mmcblk2 bs=1M status=progress conv=fsync

간단하게 설명하면 "zst"로 압축된 파일을 "zstdcat"로 압축을 해제하여, "dd" 커맨드로 보내서 EMMC로 저장하는 커맨드이다. "wic"로 생성된 이미지를 저장하는 것보다 수배 빠르게 동작한다.

"status=progress"를 추가하면, 작업 진행 상황을 확인할 수 있어서 좋다.

Application 개발 환경 구축 (개발 툴 관련)

Application 개발 환경 구축(개발 툴 관련)과 관련하여 아래 사이트에 정리가 잘 되어 있다.

설명은 i.MX8M-Mini이지만 i.MX8M Plus에도 적용이 가능하다(동일하다고 생각해도 된다).

여기서는 VSCode를 기준으로 설명한다.

VSCode 디버그를 지원하는 rootfs 생성

VSCode 디버그를 지원하는 rootfs를 생성하려면, "<build-dir>/conf/local.conf" 파일에 아래 내용을 추가한다.

EXTRA_IMAGE_FEATURES += " \
    tools-debug \
    ssh-server-dropbear \
    "

"EXTRA_IMAGE_FEATURES"는 이미지에 포함할 추가 기능 목록을 나타낸다(링크에 자세한 내용이 설명되어 있다).

VSCode로 디버깅하려면, 선호하는 SSH 서버(openssh, dropbear 등), gdb 또는 gdbserver가 대상 디바이스에 설치되어 있어야 한다.

tools-debug : gdb, strace와 같은 디버깅 도구를 설치한다.
ssh-server-dropbear : Dropbear 최소 기능의 SSH 서버를 설치한다.

rootfs를 생성한 후 대상 디바이스에 이미지를 저장(플래싱)한다.

호스트 PC 환경 설정

대상 호스트 PC에 Ubuntu 20.04가 설치되어 있다고 가정하고 설명한다.

필요한 패키지를 아래와 같이 설치한다(Yocto 이미지를 빌드하는 호스트라면 이미 설치되어 있다고 나올 수 있다).

$ sudo apt-get -y update
$ sudo apt-get -y install build-essential gdb gdb-multiarch git

리눅스용 VScode를 아래와 같이 설치한다.

$ sudo snap install --classic code

VSCode의 확장 기능을 아래와 같이 설치한다.

$ code --install-extension ms-vscode.cpptools

커맨드 실생 후 C/C++과 관련된 확장 기능이 설치된다.

Yocto Toolchain(SDK)을 설치한다(SDK 설치). SDK는 "Yocto Command 정리"의 "SDK 빌드"를 참고하여 빌드 후 생성된 SDK를 설치하면 된다(설치 경로를 꼭 확인한다).

VSCode에서 프로젝트 생성, 컴파일 및 실행

여기서는 OpevCV를 이용하여 카메라 영상을 캡쳐하여 디스플레이하는 단순한 Application을 만들면서 설명한다.

호스트 PC에서 아래와 같이 프로젝트 디렉터리를 생성하고, VSCode를 실행한다.

$ mkdir ~/opencv-test
$ cd ~/opencv-test
$ code .

"opencv-test" 디렉터리를 생성하고 "opencv-test" 디렉터리로 이동 후, VSCode를 실행한다.

아래와 같은 화면이 나온다(Ubuntu를 WSL2 상에서 실행하기 때문에 WSL이라는 문구를 볼 수 있다).

VSCode 실행 화면

"opencv-test" 디렉터리에 아래 테이블과 같이 파일과 디렉터리를 생성한다.

파일 및 경로	설명
main.cpp	샘플 프로그램 opencv-test.bin의 소스 코드.
Makefile	main.cpp를 opencv-test.bin으로 크로스 컴파일하기 위한 Makefile.
.vscode/settings.json	SDK/toolchain에 대한 전역 환경 변수를 구성하는 VSCode 파일.
.vscode/tasks.json	새로운 작업을 재정의하거나 추가하는 VSCode 파일. VSCode 빌드 커맨드가 실행될 때 Makefile이 실행된다.
.vscode/c_cpp_properties.json	IntelliSense의 포함 경로를 구성하는 VSCode 파일.

파일이나 디렉터리를 생성하려면, VSCode의 "EXPLORER"에서 마우스 오른쪽을 클릭하고 "New File...", "New Folder..."를 선택한다.

파일과 디렉터리 생성 후 화면

main.cpp의 코드는 아래와 같다.

#include <opencv2/opencv.hpp>
#include <iostream>

using namespace std;
using namespace cv;

int main(){
	// Create a VideoCapture object
	VideoCapture cap(2);

	// Check if camera opened successfully
	if(!cap.isOpened()){
		cout << "Error opening video stream" << endl;
		return -1;
	}

	while(1) {
		Mat frame;

		// Capture frame-by-frame
		cap >> frame;

		// If the frame is empty, break immediately
		if (frame.empty())
			break;

		// Display the resulting frame
		imshow( "Frame", frame );

		// Press ESC on keyboard to exit
		char c = (char)waitKey(1);
		if( c == 27 )
			break;
	}

	// When everything done, release the video capture
	cap.release();

	// Closes all the frames
	destroyAllWindows();
	return 0;
}

간단하게 소스 코드를 설명하면, 캡처 디바이스로 "/dev/video2"를 열고 프레임을 캡처하여 화면에 이미지를 보여주는 간단한 코드이다. 사용하는 환경에 맞게 캡처 디바이스를 수정해서 사용하면 된다.

main.cpp를 크로스 컴파일하기 위한 Makefile의 내용은 아래와 같다.

INC_DIRS	= -I$(SDKTARGETSYSROOT)/usr/include/opencv4

LIB_DIRS	= -L$(SDKTARGETSYSROOT)/usr/lib

LIBS		= -lopencv_core
LIBS		+= -lopencv_videoio
LIBS		+= -lopencv_highgui

all: main.cpp
	$(CXX) $(CXXFLAGS) $(INC_DIRS) $(LIB_DIRS) $(LIBS) main.cpp -g -o opencv-test.bin 
	
clean:
	rm -f opencv-test.bin

"INC_DIRS"는 추가할 헤더 파일이 존재하는 디렉터리를 설정한다.

"LIB_DIRS"는 추가할 라이브러리 파일이 존재하는 디렉터리를 설정한다.

"LIBS"는 추가할 라이브러리 파일을 설정한다.

".vscode/settings.json"의 내용은 아래와 같다.

{
	"OPENCV_APP": {
		/* 대상 디바이스의 IP 주소 */
		"TARGET_IP":"192.168.0.16",

		/* 프로젝트 설정 */
		"PROGRAM":"opencv-test.bin",

		/* Yocto SDK Configuration */
		"ARCH":"aarch64-poky-linux",
        	"OECORE_NATIVE_SYSROOT":"/opt/fsl-imx-wayland/6.1-langdale/sysroots/x86_64-pokysdk-linux",
        	"SDKTARGETSYSROOT": "/opt/fsl-imx-wayland/6.1-langdale/sysroots/armv8a-poky-linux",

		/* Yocto SDK Constants */
        	"CC_PREFIX": "${config:OPENCV_APP.OECORE_NATIVE_SYSROOT}/usr/bin/${config:OPENCV_APP.ARCH}/${config:OPENCV_APP.ARCH}-",
		"CXX": "${config:OPENCV_APP.CC_PREFIX}g++ --sysroot=${config:OPENCV_APP.SDKTARGETSYSROOT}",
		"CC": "${config:OPENCV_APP.CC_PREFIX}gcc --sysroot=${config:OPENCV_APP.SDKTARGETSYSROOT}",		
	},
	"files.associations": {
		"iostream": "cpp",
		"ostream": "cpp"
	}
}

".vscode/settings.json"에는 대상 디바이스에 대한 정보, Yocto SDK의 toolchain 정보, 기본적인 컴파일 전역 환경 변수를 설정한다.

다른 json 파일에서 "${config:OPENCV_APP.TARGET_IP}"와 같은 구문으로 접근할 수 있다.

전역 변수	설명
TARGET_IP	imx8mp-evk 대상 디바이스의 IP 주소를 설정한다.
PROGRAM	Makefile에서 생성하는 바이너리 이름과 일치해야 한다.
ARCH	gcc, g++, gdb 등에서 사용하는 아키텍처 prefix를 설정한다.
OECORE_NATIVE_SYSROOT	Yocto SDK가 설치된 경로의 environment-setup-armv8a-poky-linux에 의해 설정되는 OECORE_NATIVE_SYSROOT 환경 변수와 동일하게 설정한다.
SDKTARGETSYSROOT	Yocto SDK가 설치된 경로의 environment-setup-armv8a-poky-linux에 의해 설정되는 SDKTARGETROOT 환경 변수와 동일하게 설정한다.
CC_PREFIX	toolchain gcc, g++ 등 바이너리에 대한 전체 경로를 설정한다.
CXX	크로스 컴파일러 g++ 바이너리와 sysroot의 경로를 설정한다.
CC	크로스 컴파일러 gcc 바이너리와 sysroot의 경로를 설정한다.

".vscode/tasks.json"은 세 개의 root 개체가 있다.

options : Makefile에서 사용하는 CC, CXX 환경 변수를 정의한다.
presentation : 모든 task에 대한 VSCode의 통합된 터미널의 동작을 구성한다.
tasks : task 구성의 나열이다. 아래 내용은 VSCode의 "Run Build Task..."가 실행될 때 Makefile을 실행하는 단일 빌드 작업을 생성한다.

{
    "version": "2.0.0",
    /* Configure Yocto SDK Constants from settings.json */
    "options": {
        "env": {
            "CXX": "${config:OPENCV_APP.CXX}",         /* Used by Makefile */
            "CC": "${config:OPENCV_APP.CC}",           /* Used by Makefile */
        }
     },
     /* Configure integrated VS Code Terminal */
     "presentation": {
        "echo": false,
        "reveal": "always",
        "focus": true,
        "panel": "dedicated",
        "showReuseMessage": true,
    },
    "tasks": [        
        /* Configure Build Task */
        {
            "label": "build",
            "type": "shell",
            "command": "make clean; make -j$(nproc)",
            "problemMatcher": ["$gcc"]
        },
    ]
}

".vscode/c_cpp_properties.json"은 IntelliSense에 대한 포함 경로를 구성한다.

내용은 아래와 같다.

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**",
                "${config:OPENCV_APP.SDKTARGETSYSROOT}/usr/include/**"
            ]
        }
    ],
    "version": 4
}

프로젝트를 빌드하기 전에 Yocto SDK가 설치된 경로의 "environment-setup-armv8a-poky-linux"를 실행해야 한다.

아래와 같이 실행한다. 경로는 설치 위치에 따라 달라진다.

$ source /opt/fsl-imx-wayland/6.1-langdale/environment-setup-armv8a-poky-linux
$ export LDFLAGS=

VSCode에서 프로젝트를 빌드하려면, "Terminal->Run Build Task..."를 실행하거나 "Ctrl + Shift + B" 단축키를 사용한다.

빌드 후 화면 (opencv-test.bin 파일이 생성됨)

생성된 바이너리를 대상 디바이스에 배포하기 위해, "Terminal->New Terminal"을 실행하거나 "Ctrl + Shift + `" 단축키를 사용한다.

터미널이 실행되면 아래와 같이 scp 커맨드로 생성된 바이너리를 대상 디바이스에 배포한다.

$ scp opencv-test.bin root@192.168.0.16:/home/root

IP 주소는 ".vscode/settings.json"의 TARGET_IP와 동일하다.

대상 디바이스의 터미널에서 배포한 바이너리를 실행한다.

# ./opencv-test.bin

VSCode를 사용한 원격 디버깅

VSCode에서 디버깅을 활성화하기 위해서 ".vscode/tasks.json" 파일의 수정과 "deploy_gdb.sh", ".vscode/launch.json" 파일들이 추가적으로 필요하다.

파일 및 경로	설명
deploy-gdb.sh	gdbserver를 배포하고 실행하는 일반 스크립트
.vscode/launch.json	디버그 구성을 설정하는 VSCode 파일. tasks.json에서 deploy-gdb를 실행.
.vscode/tasks.json	디버깅하기 전에 deploy-gdb.sh를 호출하도록 편집.

deploy-gdb.sh 파일 생성

먼저 프로그램 배포를 위한 일반 스크립트를 추가하고 gdbserver를 실행한다. 스크립트에는 두 가지 인수가 필요하다.

TARGET_IP : 대상 디바이스의 IP 주소
PROGRAM : 바이너리 실행 파일의 이름(여기서는 opencv-test.bin)

결국 tasks.json은 각 디버그 세션이 시작될 때 이 스크립트를 실행한다.

아래는 "deploy-gdb.sh"의 내용이다.

#!/bin/bash
readonly TARGET_IP="$1"
readonly PROGRAM="$2"
readonly TARGET_DIR="/home/root"


# Must match startsPattern in tasks.json
echo "Deploying to target"

# kill gdbserver on target and delete old binary
 ssh root@${TARGET_IP} "sh -c '/usr/bin/killall -q gdbserver; rm -rf ${TARGET_DIR}/${PROGRAM}  exit 0'"

# send the program to the target
 scp ${PROGRAM} root@${TARGET_IP}:${TARGET_DIR}

# Must match endsPattern in tasks.json
echo "Starting GDB Server on Target"

# start gdbserver on target
 ssh -t root@${TARGET_IP} "sh -c 'cd ${TARGET_DIR}; gdbserver localhost:3000 ${PROGRAM}'"

.vscode/launch.json 파일 생성

VSCode에는 다양한 프로그램 언어를 디버깅할 수 있는 강력한 디버거가 내장되어 있다. 여기서는 C/C++ Extension을 사용하여 디버깅을 구성을 추가한다.

아래는 ".vscode/launch.json"의 내용이다.

{
    "version": "0.2.0",
    "configurations": [        
        {
        "name": "GDB debug",
        "type": "cppdbg",
        "request": "launch",
        "program": "${config:OPENCV_APP.PROGRAM}",
        "args": [],
        "stopAtEntry": true,
        "cwd": "${workspaceFolder}",
        "environment": [],
        "console": "integratedTerminal",
        "MIMode": "gdb",
        "targetArchitecture": "arm64",
        "preLaunchTask": "deploy-gdb",
        "setupCommands": [{
            "description": "Enable pretty-printing for gdb",
            "text": "-enable-pretty-printing",
            "ignoreFailures": true
        }],
        "miDebuggerPath": "/usr/bin/gdb-multiarch",
        "miDebuggerServerAddress": "${config:OPENCV_APP.TARGET_IP}:3000",
    }]
}

주요 변수에 대한 세부 정보는 아래 테이블을 참조한다.

변수	설명
miDebuggerServerAddress	대상 디바이스의 IP 주소와 일치해야 한다.
program	Makefile에서 생성한 바이너리의 이름과 일치해야 한다.
preLaunchTask	.vscode/tasks.json의 다음 단계의 task 이름과 일치해야 한다.

.vscode/tasks.json 파일 편집

".vscode/launch.json"에서는 각 디버깅 세션의 시작부분에서 deploy-gdb 이름의 task를 실행하기 위해 preLaunchTask를 만들었다. 이 task는 ".vscode/tasks.json"에서 새로운 task인 deploy-gdb 추가하여 구성된다.

아래는 최종 ".vscode/tasks.json" 파일의 내용이다.

{
    "version": "2.0.0",
    /* Configure Yocto SDK Constants from settings.json */
    "options": {
        "env": {
            "CXX": "${config:OPENCV_APP.CXX}",         /* Used by Makefile */
            "CC": "${config:OPENCV_APP.CC}",           /* Used by Makefile */
        }
     },
     /* Configure integrated VS Code Terminal */
     "presentation": {
        "echo": false,
        "reveal": "always",
        "focus": true,
        "panel": "dedicated",
        "showReuseMessage": true,
    },
    "tasks": [
        /* Configure launch.json (debug) preLaunchTask Task */
        {
            "label": "deploy-gdb",
            "isBackground": true,
            "problemMatcher":{
                "base": "$gcc",
                "background": {
                    "activeOnStart": true,
                    "beginsPattern":  "Deploying to target",
                    "endsPattern":  "Starting GDB Server on Target"
                }
            },
            "type": "shell",
            "command": "sh",
            "args": [
                "deploy-gdb.sh",
                "${config:OPENCV_APP.TARGET_IP}",
                "${config:OPENCV_APP.PROGRAM}"
            ],
            "dependsOn": ["build"],
        },
        /* Configure Build Task */
        {
            "label": "build",
            "type": "shell",
            "command": "make clean; make -j$(nproc)",
            "problemMatcher": ["$gcc"]
        },
    ]
}

아래 테이블은 deploy-gdb 구성을 설명한다.

변수	설명
label	.vscode/launch.json의 preLaunchTask와 일치해야 한다.
type	이 task는 shell을 실행한다.
command	"deploy-gdb.sh 192.168.0.16 opencv-test.bin" 인수로 sh를 실행한다.

디버깅 세션 실행

위의 단계를 수행하면 아래와 같은 파일들이 있어야 한다.

최종 파일 목록

"Run->Start Debugging"을 선택하거나 "F5"를 눌러서 새로운 디버깅 세션을 시작할 수 있다.

VSCode는 디버그 모드로 전환하고 대상 디바이스에서 gdbserver를 실행하는 gnome-terminal을 실행한다.

VSCode 디버그 모드

사용자 정의 디바이스 트리 적용

기본으로 제공되는 디바이스 트리를 사용하지 않고, 사용자 정의된 디바이스 트리를 사용하는 경우 아래의 절차를 따른다.

imx8mp_evk를 기준으로 설명한다.

기본으로 제공되는 디바이스 트리를 참고하여, 사용자 정의 디바이스 트리를 작성한다.
Yocto Project의 "<build-dir>/<work-shared>/<machine>/kernel-source/arch/arm64/boot/dts/freescale/"에서 기본으로 제공되는 디바이스 트리 파일을 찾을 수 있다.
사용자 정의 디바이스 트리 파일은 작성 후 위와 동일한 디렉터리에 있어야 한다.
같은 디렉터리에 있는 Makefile에 사용자 정의 디바이스 트리 파일을 추가한다.
dtb-$(CONFIG_ARCH_MXC) += <사용자 정의 디바이스 트리 파일 이름>.dtb
"<meta-레이어>/conf/machine/<machine>.conf" 파일에 사용자 정의 디바이스 트리 파일을 추가한다.
"KERNEL_DEVICETREE += "<사용자 정의 디바이스 트리 파일 이름>.dtb""
예로 imx8mp을 사용하는 경우, "source/meta-imx/meta-bsp/conf/machine/imx8_all.conf"에 추가한다.
u-boot에서 defconfig 파일을 수정한다.
Yocto Project의 "<build-dir>/<work>/<machine>-poky-linux/u-boot-imx/<version>-r0/git/configs/imx8mp_evk_defconfig" 파일에서 아래 항목을 수정한다.
CONFIG_DEFAULT_DEVICE_TREE="<사용자 정의 디바이스 트리>"
CONDIF_DEFAULT_FDT_FILE="<사용자 정의 디바이스 트리>.dtb"

위의 절차대로 수정 후 다시 이미지를 빌드한다. u-boot에서 defconfig를 수정하지 않으면, 기본 디바이스 트리 파일을 로드하므로 꼭 수정을 해야 한다.

[이전] [목차] [다음]

AN13709 - References

까마귀75 — Tue, 23 May 2023 12:02:15 +0900

[이전] [목차] [다음]

8 References

i.MX 8M Nano Applications Processor Reference Manual (IMX8MNRM 문서)
Presentation: Understanding U-Boot Falcon Mode, Michael Opdenacker, June 3rd 2021
U-Boot Source Code - Falcon README

[이전] [목차] [다음]

AN13709 - Results

까마귀75 — Tue, 23 May 2023 11:43:45 +0900

[이전] [목차] [다음]

7 Results

Table 2. Initial Linux boot time measurements

	SPL			U-BOOT				KERNEL
No.	BOOTROM	DDR initialization	SPL initializations + Load UBoot image	U-Boot initializations (init_ sequence_f)	U-Boot initializations (init_ sequence_r)	Boot sequence	Kernel image load	Kernel boot until PSPLASH image	Total time
	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)
1	260	253	285	594	906	3651	329	5768	12046
2	299	253	285	594	1016	3852	328	5920	12547
3	258	252	284	587	901	3730	328	5902	12242
4	257	253	284	587	896	3726	328	5846	12177
5	261	253	284	587	896	3726	328	5975	12310
Average time (ms)	805			5579				5883	12264

Table 3. Optimized Linux boot time measurements

	SPL				KERNEL
No.	BOOTROM	DDR initialization	SPL initializations	Kernel Image Load	Kernel Boot Until PSPLASH Image	Total time
	(ms)	(ms)	(ms)	(ms)	(ms)	(ms)
1	262	252	128	460	2661	3763
2	264	253	130	461	2772	3880
3	249	252	129	460	2924	4014
4	255	252	129	460	2717	3813
5	253	253	131	461	2594	3692
Average time (ms)	1099				2734	3832

[이전] [목차] [다음]

AN13709 - User space optimizations

까마귀75 — Tue, 23 May 2023 11:01:50 +0900

[이전] [목차] [다음]

6 User space optimizations

사용자 공간에서 소비되는 시간을 줄이는 가장 쉬운 방법은 애플리케이션이 실행되는 순서를 재정렬하는 것이다. psplash 서비스를 더 빨리 시작하려면, Systemd가 작동하는 종속성을 변경해야 한다.

보드에서 /lib/systemd/system/psplash-start.service 파일을 열고, psplash가 local-fs-pre.target보다 먼저 시작되도록 수정하여 디바이스 종속성을 변경한다.

[Unit]
Description=Start Psplash Boot Screen
#Wants=systemd-vconsole-setup.service
#After=systemd-vconsole-setup.service systemd-udevtrigger.
service systemd-udevd.service
Before=local-fs-pre.target
DefaultDependencies=no

system-analyze 커맨드가 blame 인수와 함께 호출되면, Systemd는 서비스와 시작 시간을 출력하는 systemd-analyze라는 유틸리티도 제공한다.

$ systemd-analyze blame

서비스를 비활성화하려면, systemctl disable 커맨드를 사용할 수 있다. 일부 서비스(특히 systemd에서 제공하는 서비스)는 비활성화하려면 systemctl mask 커맨드가 필요할 수 있다. 그러나 시스템이 제대로 작동하기 위해 서비스에 의존할 수 있으므로 서비스를 비활성화할 때 주의해야 한다.

[이전] [목차] [다음]

AN13709 - Kernel space optimizations

까마귀75 — Mon, 22 May 2023 14:03:35 +0900

[이전] [목차] [다음]

5 Kernel space optimizations

5.1 Adding quiet

Kernel 시간을 절반 정도 줄이려면, Kernel bootargs에 quiet 인수를 추가한다. 이는 Linux 시작 시퀀스 중에 일부 메세지를 표시하지 않는다.

spl export 커맨드를 사용하여, 새로운 bootargs로 디바이스 트리를 다시 생성해야 한다.

기본 부팅 모드로 재부팅한다.
1. <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/include/configs/imx8mn_evk.h에서 CONFIG_SPL_OS_BOOT의 정의를 주석 처리한다.
2. 20단계(4.3 참조)에서와 같이 부트로더를 다시 컴파일하고 다시 저장한다.
U-Boot로 진입하고 quiet를 추가하여 bootargs 파라미터를 편집한다.

u-boot=> edit bootargs
edit: console=ttymxc1,115200 root=/dev/mmcblk1p2 rootwait rw quiet
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK

18단계(4.3 참조)에서와 같이 디바이스 트리를 다시 생성하고 SDHC에 로드한다.
19단계, 20단계(4.3 참조)를 수행하여 Falcon 모드로 다시 진입한다.

5.2 Removing unnecessary drivers and file systems

사용 용도에 따라 불필요한 드라이버와 파일 시스템을 제거하여 Kernel을 줄일 수 있다. 초기화 중에 커널에서 발생하는 일을 그래프로 표시할 수 있는 커널 기능인 bootgraph를 사용하여 부팅 중에 커널 기능을 분석할 수 있다.

bootgraph를 생성하려면 다음 단계를 수행한다.

Kernel bootargs에 initcall_debug를 추가한다.
1. 1단계(4.3 참조)와 같이 기본 부팅 모드로 재부팅한다.
2. U-Boot로 진입하고 initcall_debug를 추가하여 bootargs 파라미터를 편집한다.

u-boot=> edit bootargs
edit: console=ttymxc1,115200 root=/dev/mmcblk1p2 rootwait rw quiet initcall_debug
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK

18단계(4.3 참조)에서와 같이 디바이스 트리를 다시 생성하고 SDHC에 로드한다.
19단계, 20단계(4.3 참조)를 수행하여 Falcon 모드로 다시 진입한다.
보드를 부팅하고 Kernel 로그를 가져온다.

root@imx8mn-lpddr4-evk:~# dmesg > boot.log

호스트로 돌아가서 다음 커맨드를 사용하여 그래프를 생성한다.

$ cd <yocto_build_dir>/tmp/work-shared/imx8mn-lpddr4-evk/kernel-source/scripts
$ ./bootgraph.pl boot.log > boot.svg

아래와 같은 것을 얻을 수 있으며, Kernel 부팅 시간이 어떻게 사용되는지 분석할 수 있다.

Figure 4. Function timeline during kernel boot

드라이버 기능을 비활성화하려면, Kernel 구성을 업데이트해야 한다.
예를 들어 Kernel(이미지 크기를 줄임)과 UBI 파일 시스템에서 디버그를 비활성화했다.

sources/meta-imx/meta-bsp/recipies-kernel/linux/files에서 다음 라인을 포함하는 조각 구성 파일 frag.cfg를 만든다.

# CONFIG_UBIFS_FS is not set
# CONFIG_DEBUG_KERNEL is not set

이것을 기본 구성 파일과 병합하려면, 새로운 레시피를 추가해야 한다. sources/meta-imx/meta-bsp/recipies-kernel/linux에 linux-imx_5.10.bbappend를 생성하고 다음 라인을 추가한다.

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://frag.cfg \
      "
DELTA_KERNEL_DEFCONFIG = "frag.cfg"

새로운 구성으로 Kernel을 다시 컴파일하고, mkimage로 uImage를 변환하여 SD에 저장한다.

$ bitbake -c cleansstate virtual/kernel
$ bitbake -f -c compile virtual/kernel

17단계(4.3 참조)와 같이 커널 이미지를 uImage로 변환한다.
uImage Kernel을 SD 카드에 저장한다.

참고:
저장 장치의 위치는 다를 수 있다. SD 카드 위치를 가리키려면 of 파라미터를 조정한다.
dd if=uImage of=/dev/sdb bs=512 seek=50000100 conv=fsync

[이전] [목차] [다음]

AN13709 - Bootloader optimizations

까마귀75 — Tue, 16 May 2023 10:36:41 +0900

[이전] [목차] [다음]

4 Bootloader optimizations

4.1 Default boot mode

Figure 1은 기본 부팅 순서를 보여준다. 전원을 켜거(power-on)나 재설정(reset)한 후, i.MX8M은 ROM(Read Only Memory)에 저장된 BootROM(the primary program loader:기본 프로그램 로더)을 실행한다. BootROM은 PLL(Phase Locked Loops), 클럭 구성, 메모리 초기화(SRAM)와 같은 기본적인 주변 장치 초기화를 수행하여 SoC(System-on-Chip)를 구성한 다음 부트로더 이미지를 로드할 수 있는 부트 디바이스를 찾는다. U-Boot SPL, ATF, U-Boot 등의 구성 요소가 부트 디바이스에 포함될 수 있다.

Figure 1. Default boot sequence

일반적인 U-Boot 이미지는 내부 SRAM에 맞지 않기 때문에, SPL(Secondary Program Loader)과 U-Boot proper 두 부분으로 나뉜다.

SPL은 부트로더의 첫 번째 단계로, U-Boot와 동일한 소스를 공유하지만 SRAM에 맞는 최소한의 코드 세트를 가지는 더 작은 프리로더(pre-loader)이다. SPL은 SRAM에 로드된다. 일부 주변 장치와 가장 중요한 DRAM을 구성하고 초기화한다. 그런 다음 ATF와 U-Boot proper을 DRAM에 로드한다. 마지막 단계는 ATF로 이동하는 것이며, ATF는 다시 U-Boot proper로 이동한다.

최신 i.MX8* 제품군에 포함된 ATF(Arm Trusted Firmware)는 Armv8 아키텍처를 위한 신뢰할 수 있는 코드 기반의 레퍼런스를 제공한다. PSCI(Power State Coordination Interface)를 비롯한 다양한 ARM 인터페이스 표준을 구현한다. 바이너리는 일반적으로 부트로더 바이너리에 포함되어 있다. U-Boot의 초기 단계에서 시작된다. ATF가 없으면, 커널은 Secure World 환경에서 실행해야 하는 서비스를 설정할 수 없다.

U-Boot proper는 두 번째 단계의 부트로더이다. Linux Kernel을 로드하고 시작하는 유연한 방법을 제공하며 커맨드라인 인터페이스로 보드의 하드웨어와 상호 작용할 수 있는 최소한의 도구 세트를 제공한다. DRAM에서 실행되어 추가적인 하드웨어 디바이스(네트워크, USB, DSI/CSI 등)를 초기화한다. 그런 다음 디바이스 트리(FDT)를 로드하고 준비한다. U-Boot가 처리하는 주요 작업은 커널 이미지 자체를 로드하고 시작하는 것이다.

Linux Kernel은 DRAM에서 실행되며 시스템을 완전히 장악한다. U-Boot는 이 시점부터 더 이상 시스템을 제어할 수 없다.

4.2 Falcon mode

Falcon 모드는 U-Boot의 기능으로 SPL에서 Linux 커널을 직접 시작하여 U-Boot 로딩과 초기화를 완전히 건너뛰어 부트로더에서 소요되는 시간을 줄이는 효과가 있어 빠른 부팅을 가능하게 한다.

Figure 2는 Falcon 모드의 부팅 순서를 보여준다.

Figure 2. Falcon mode boot sequence

이 모드를 구현하려면 다음 작업을 수행해야 한다.

Falcon에 대한 몇 가지 특정 구성을 활성화한다.
FDT(Flattened Device Tree)를 미리 준비한다.
커널로 이동하도록 ATF를 구성한다.
SD 카드에서 ATF, 커널 이미지와 FDT를 파티션 외부의 로우 섹션에 저장한다.
SPL을 수정하여 ATF와 커널을 로드한 다음 ATF로 이동한다.

4.3 Implementation

다음 수정은 Yocto 환경이 설치된 호스트 컴퓨터에서 이루어진다.

참고:
Windows에서는 MSYS2를 설치하여 dd 커맨드(Linux 용)를 사용할 수 있다. Windows용으로 컴파일된 GNU/Linux Tools이다.

구성 파일에서 SPL BootROM 지원을 제거한다.

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/configs/imx8mn_evk_defconfig

# CONFIG_SPL_BOOTROM_SUPPORT is not set

SD에서 로우 데이터 읽기에 대한 지원을 추가하고, spl export 커맨드를 활성화하고, 레거시 이미지에 대한 지원을 추가하여 Falcon 모드에 대한 특정 구성을 만든다.

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/include/configs/imx8mn_evk.h

#define CONFIG_CMD_SPL 1 // enable spl export command
#define CONFIG_SPL_MMC_SUPPORT 1 // for reading from MMC
#define CONFIG_SPL_LEGACY_IMAGE_SUPPORT 1

/* Falcon Mode */
//#define CONFIG_SPL_OS_BOOT 1 // activate Falcon Mode
 /* (leave this line commented until you finish all the
 configurations) */

// RAM FDT address
#define CONFIG_SYS_SPL_ARGS_ADDR 0x43000000

/* Falcon Mode - MMC support */
#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x2FAF080
#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 0x58
#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 0x2FAF0E4

U-Boot 부팅이 첫 번째 선택이 아님을 나타내기 위해 0을 반환하는 spl_start_uboot() 함수를 구현한다.

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/board/freescale/imx8mn_evk/spl.c

#ifdef CONFIG_SPL_OS_BOOT
int spl_start_uboot(void) {
    return 0;
}
#endif

else 문(로드에 헤더가 포함된 경우)에서 spl_parse_legacy_header() 함수의 Kenel 로드 주소 계산 모드를 수정한다.

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/common/spl/spl_legacy.c

다음 라인을

spl_image->load_addr = image_get_load(header) - header_size;

아래와 같이 변경한다.

spl_image->load_addr = image_get_ep(header) - header_size;

mmc_load_legacy() 함수에서 기존 코드 뒤에 다음 라인을 추가하여 AFT를 로드한다.

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/common/spl/spl_mmc.c

/* existing code */
count = blk_dread(mmc_get_blk_desc(mmc), sector,
 image_size_sectors, (void *)(ulong)spl_image->load_addr);
/* end of existing code */
unsigned long count1 = blk_dread(mmc_get_blk_desc(mmc), 0x2FBDAE0, 0x71,
 (void*)(ulong)0x00960000); //write ATF from SD to RAM

board_init_r() 함수에서 ATF로 이동하도록 SPL을 수정한다(Linux 상태로 이동).

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/common/spl/spl.c

#ifdef CONFIG_SPL_OS_BOOT
       case IH_OS_LINUX:
       debug("Jumping to Linux\n");
#if defined(CONFIG_SYS_SPL_ARGS_ADDR)
      spl_fixup_fdt((void *)CONFIG_SYS_SPL_ARGS_ADDR);
#endif
       spl_board_prepare_for_linux();
       typedef void __noreturn (*image_entry_noargs_t)(void);
       image_entry_noargs_t image_entry = (image_entry_noargs_t)0x00960000;
       image_entry();
#endif

참고 :
CONFIG_SPL_OS_BOOT가 정의되면, SPL은 오류를 발생시켜 CPU를 재설정하기 위해 dram_init_banksize() 함수를 호출한다. 이는 <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/arch/arm/mach-imx/imx8m/soc.c 소스 파일에서 gd->bd 구조체를 사용하기 전에 메모리를 할당하여 피할 수 있는 초기화되지 않은 함수의 사용으로 인해 발생한다.

gd->bd = (struct bd_info*)malloc(sizeof(struct bd_info));

Ethernet MAC이 PHY와 상호 작용할 수 있는 작동되는 상태로 가져오려면, U-Boot SPL이나 Linux에서 Ethernet PHY를 재설정해야 한다. 다음 지침은 U-Boot SPL에서 PHY를 재설정하는 자세한 방법을 설명한다.

FEC 디바이스에 연결된 핀을 확인한다. 이것은 i.MX8MN EVK 보드의 관련 DTS 파일에 설명되어 있다.
위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx<specified_git_folder>/git/arch/arm/dts/imx8mn-evk.dtsi

보드 회로도에 따르면 Ethernet PHY의 리셋 핀은 그룹 4, 핀 22(빨간색으로 표시)에 연결되어 있다.

파일에 GPIO 그룹과 GPIO 핀 쌍을 포함하는 매크로를 선언한다. 패드를 GPIO로 사용하는 매크로를 추가한다.
위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/common/spl/spl.c

#define RESET_ETH_GPIO IMX_GPIO_NR(4,22)
#define USDHC_GPIO_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE1)

board_init_r() 함수에 다음 라인을 추가하여 Ethernet PHY를 재설정한다.
위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/common/spl/spl.c

/*reset eth*/
gpio_request(RESET_ETH_GPIO, "reset_eth_gpio");
gpio_direction_output(RESET_ETH_GPIO, 0);
mdelay(1);
gpio_direction_output(RESET_ETH_GPIO, 1);
mdelay(1);

패치를 만들기 전에, 모든 새로운 수정 사항이 올바른지 확인해야 한다. 호스트에서 다음 bitbake 커맨드를 사용하여 U-Boot 이미지를 다시 빌드한다.

$ bitbake -f -c configure u-boot-imx
$ bitbake -f -c compile u-boot-imx
$ bitbake u-boot-imx imx-boot

설정이 완료되면, U-Boot 수정 사항이 포함된 패치를 생성한다.

$ git add –-all
$ git commit –s
$ git format-patch HEAD~1

생성된 패치를 imx-yocto-bsp/sources/ meta-imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx 위치에 복사한 다음, U-Boot에 대한 Yocto 레시피(imx-yocto-bsp/sources/meta-imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2021.04.bb)에서 소스 위치 식별자에 패치 이름을 추가한다.

SRC_URI = "... \
       file://<patch_name>.patch \
      "

수정 후 패치가 작동하는지 확인하려면, 다음 커맨드를 적용한다. 그러면 파일에 최신 변경 사항이 포함되어야 한다.

$ bitbake -f -c cleansstate u-boot-imx
$ bitbake u-boot-imx imx-boot

SPL만으로 부트로더 이미지를 생성한다.

<yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/imx-boot/<specified_git_folder>/git/iMX8M/soc.mak 파일에서 새 이미지를 빌드하기 위한 새로운 대상을 생성한다.

보드가 HDMI로 구성되어 있으면, ifeq($(HDMI),yes) 조건에서 다음 라인을 추가한다.

flash_evk_falcon: $(MKIMG) signed_hdmi_imx8m.bin u-boot-spl-ddr.bin
        ./mkimage_imx8 -fit -signed_hdmi
 signed_hdmi_imx8m.bin -loader u-boot-spl-ddr.bin
 $(SPL_LOAD_ADDR) -out $(OUTIMG)

그렇지 않으면, HDMI를 포함하지 않는 새로운 대상을 만들고 구현한다.

flash_evk_falcon: flash_evk_falcon_no_hdmi

flash_evk_falcon_no_hdmi: $(MKIMG) u-boot-spl-ddr.bin
      ./mkimage_imx8 -version $(VERSION) -loader u-boot-spl-ddr.bin
$(SPL_LOAD_ADDR) -out $(OUTIMG)

flash.bin(imx-boot image)을 다시 생성하려면, make SOC=iMX8MN flash_evk_falcon을 실행한다.

위의 수정 사항을 포함하는 패치를 만든다.

$ git add soc.mak
$ git commit –s
$ git format-patch HEAD~1

만들어진 패치를 ~/imx-yocto-bsp/sources/meta-imx/meta-bsp/recipes-bsp/imx-mkimage/files에 복사한 다음, imx-mkimage(~/imx-yocto-bsp/sources/meta-imx/meta-bsp/recipes-bsp/imx-mkimage/imx-mkimage_git.inc)에 대한 Yocto 레시피의 소스 위치 식별자에 패치 이름을 추가한다.

SRC_URI = "... \
      file://<patch_name>.patch \
      "

수정 후 패치가 작동하는지 확인하려면 다음 커맨드를 적용한다. 그러면 파일에 최신 변경 사항이 포함되어야 한다.

$ bitbake –f –c cleansstate imx-boot
$ bitbake imx-boot
$ make SOC=iMX8MN flash_evk_falcon

SD 카드에 부트로더 이미지를 저장한다.

참고:
저장 장치의 위치는 다를 수 있다. SD 카드 위치를 가리키도록 of 파라미터를 조정한다.

dd if=flash.bin of=/dev/sdb bs=1k seek=32 conv=fsync

Kernel 이미지로 이동하도록 ATF를 구성한다.

bl31_early_platform_setup2() 함수에서 bl33_image_ep_info 구조체의 프로그램 카운터 멤버를 커널 주소로 설정하고 FDT의 주소를 인자로 설정한다.

위치 : <yocto_build_dir>/tmp/work/cortexa53-crypto-mx8mn-poky-linux/imx-atf/<specified_git_folder>/git/plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c

//bl33_image_ep_info.pc = PLAT_NS_IMAGE_OFFSET;
bl33_image_ep_info.pc = 0x40400000; // RAM kernel address
bl33_image_ep_info.spsr = get_spsr_for_bl33_entry();
// RAM FDT address
bl33_image_ep_info.args.arg0 = (u_register_t)0x43000000;
bl33_image_ep_info.args.arg1 = 0U;
bl33_image_ep_info.args.arg2 = 0U;
bl33_image_ep_info.args.arg3 = 0U;
SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE);

ATF 소스를 다시 컴파일한다.

패치를 만들기 전에 소스가 컴파일되는지 확인한다.

$ bitbake imx-atf

build/imx8mn/release 디렉토리에서 ATF 바이너리(bl31.bin)를 찾을 수 있다.

새로운 수정 사항을 포함하는 패치를 만든다.

$ git add plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c
$ git commit –s
$ git format-patch HEAD~1

결과 패치를 imx-yocto-bsp/sources/meta-imx/meta-bsp/recipes-bsp/imx-atf/files에 복사한다. 기존 레시피에 새로운 레시피를 추가(imx-atf_2.4.bbappend 파일 생성)하고 imx-yocto-bsp/sources/meta-imx/meta-bsp/recipes-bsp/imx-atf/imx-atf_ 2.4.bbappend에 다음 라인을 추가한다.

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://0001-jump-to-kernel.patch \
      "

수정 후 패치가 작동하는지 확인하려면, 다음 커맨드를 적용한다. 그러면 파일에 새로운 변경 사항이 포함되어야 한다.

$ bitbake –f –c cleansstate imx-atf
$ bitbake imx-atf

참고:
ATF를 수동으로 빌드하려면, Yocto meta-toolchain을 사용한다.

$ bitbake meta-toolchain
$ cd imx-yocto-bsp/build-wayland/tmp/deploy/sdk
$ ./fsl-imx-wayland-glibc-x86_64-meta-toolchain-cortexa53-
crypto-imx8mn-lpddr4-evk-toolchain-5.10-hardknott.sh
$ source /opt/fsl-imx-wayland/5.10-hardknott/environment-
setup-cortexa53-crypto-poky-linux; unset LDFLAGS
$ cd <yocto_build_dir>/tmp/work/cortexa53-crypto-mx8mn-poky-
linux/imx-atf/<specified_git_folder>/git
$ make PLAT=imx8mn bl31

SD 카드에 ATF를 저장한다.

참고:
저장 장치의 위치는 다를 수 있다. SD 카드 위치를 가리키려면, of 파라미터를 조정한다.

dd if=bl31.bin of=/dev/sdb bs=512 seek=50060000 conv=fsync

Kernel 이미지의 진입점(entry point)과 로드 주소를 선택한다.
커널을 부팅하기 전에, U-Boot는 커널 이미지를 2MB의 배수인 주소로 재배치한다. 이 재배치를 우회하려면 동일한 기준을 사용하여 진입점 주소를 미리 설정해야 한다(주소는 2MB의 배수여야 함). 커널이 실행될 주소는 0x40400000이다. uImage의 헤더가 64바이트인 것을 고려하면 로드 주소는 0x403fffc0이 된다.
이미지에 Kernel 레거시 uImage 파일을 빌드한다.
uImage는 Image 앞에 로더 정보(로드 주소, 진입점, OS 유형 등)가 지정된 64바이트 헤더를 추가하는 특수 이미지 파일이다.

빌드 후 Kernel 이미지가 배포되는 디렉터리를 변경한다.

$ cd <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-
linux/linux-imx/<specified_git_folder>/build/arch/arm64/boot

U-Boot의 mkimage 커맨드를 사용하여 uImage를 생성한다.

$ mkimage -A arm -O linux -T kernel -C none -a 0x403FFFC0
 -e 0x40400000 -n "Linux kernel" -d Image uImage
Image Name:   Linux kernel
Created:      Wed May 4 11:02:52 2022
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    30118400 Bytes = 29412.50 KiB = 28.72 MiB
Load Address: 403fffc0
Entry Point:  40400000

파라미터 정보:

A [architecture]: 아키텍처 설정
O [os]: 운영 체제 설정
T [image type]: 이미지 유형 설정
C [compression type]: 압축 유형을 설정
n [image name]: 이미지 이름을 이미지 이름으로 설정
d [image data file]: 이미지 데이터 파일에서 이미지 데이터를 사용
a [load address]: 16진수로 로드 주소를 설정
e [entry point]: 16진수로 진입점을 설정

Flattened Device Tree를 준비하고 SD에 저장한다.
Falcon Mode로 부팅할 때, 중요한 단계는 디바이스 트리를 준비하는 것이다. 일반적으로 U-Boot는 Linux를 부팅할 때 FDT 수정을 수행한다. 이는 초기 디바이스 트리에 U-Boot가 Kernel 인수를 추가함을 의미한다.
이러한 인수는 구성 파일 중 하나인 <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/include/configs/imx8mn_evk.h에서 bootargs라는 이름 아래에서 찾을 수 있다. 여기에 콘솔 파라미터가 지정되어 있고 루트 파일 시스템을 찾을 위치를 커널에 알려준다.
U-Boot를 스킵하기 위해서, spl export 커맨드를 이용하여 FDT를 미리 준비해야 한다. 일반 부팅에서만 호출해야 한다. 디바이스 트리 수정이 완료될 때까지 bootm을 통과하는 것과 동일한 커맨드이다. 메모리의 디바이스 트리는 falcon 모드에 필요한 것이다. 이 이미지는 CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 매크로가 지정하는 위치로 SD에 저장해야 하며, 최대 크기는 CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 매크로가 지정한다.

FDT 준비 단계:

보드를 U-Boot로 부팅하고, 자동 부팅 시퀀스에 들어가기 직전에 중지한다.
FDT를 RAM에 로드한다.

u-boot=> run loadfdt
41608 bytes read in 2 ms (19.8 MiB/s)

Kernel uImage를 RAM에 로드한다.

u-boot=> fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} uImage
30118464 bytes read in 320 ms (89.8 MiB/s)

지정된 오프셋 섹터로 Kernel Image를 SDHC에 저장한다.

u-boot=> mmc write ${loadaddr} 0x2FAF0E4 0xe5c9
MMC write: dev # 1, block # 50000100, count 58825 ... 58825
 blocks written: OK

FDT 준비

u-boot=> spl export fdt ${loadaddr} - ${fdt_addr_r}
## Booting kernel from Legacy Image at 40400000 ...
   Image Name: Linux kernel
   Created: 2022-04-08 13:08:28 UTC
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 30118400 Bytes = 28.7 MiB
   Load Address: 403fffc0
   Entry Point: 40400000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Kernel Image
   Using Device Tree in place at 0000000043000000, end 000000004300d287
subcommand not supported
subcommand not supported
   Using Device Tree in place at 0000000043000000, end 0000000043010287
Argument image is now in RAM: 0x0000000043000000

준비된 FDT를 SD 카드에 저장

u-boot=> mmc write 0x43000000 0x2FAF080 0x58

참고:
SD 카드에 FDT를 다시 저장할 수 있다. PC에서 로컬로 저장하려면, 다음 커맨드를 사용한다.
dd if=/dev/sdb of=imx8mn-evk.dtb bs=512 skip=50000000 count=88 conv=fsync

참고:
저장 장치의 위치는 다를 수 있다. SD 카드 위치를 지정하려면, of 파라미터를 조정한다.

수정 후 만들어진 SD 카드는 Figure 3과 같다.

Figure 3. SD card structure

2 단계에서의 CONFIG_SPL_OS_BOOT 정의의 주석 처리를 제거한다.
부트로더를 다시 컴파일하고 SD 카드에 저장한다.

$ bitbake -f -c configure u-boot-imx
$ bitbake -f -c compile u-boot-imx
$ cd <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/imx-boot/<specified_git_folder>/git/
$ make SOC=iMX8MN flash_evk_falcon

SD 카드에 U-Boot 이미지를 저장한다.

참고:
저장 장치의 위치는 다를 수 있다. SD 카드 위치를 지정하려면, of 파라미터를 조정한다.

dd if=flash.bin of=/dev/sdb bs=1k seek=32 conv=fsync

4.4 Improve raw MMC read performance in SPL

Falcon 모드를 구현한 후 SPL에서 소비되는 시간이 크게 증가한 것을 관찰할 수 있다. 커널 이미지가 메모리에 느리게 로드되기 때문이다(큰 크기 ~ 30MB). SPL에서 전송 속도를 높이려면 고속 지원(UHS/SD)을 추가한다.

위치 : <yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/configs/imx8mn_evk_defconfig

CONFIG_SPL_MMC_UHS_SUPPORT=y
CONFIG_SPL_MMC_IO_VOLTAGE=y

참고:
<yocto_build_dir>/tmp/work/imx8mn_lpddr4_evk-poky-linux/u-boot-imx/<specified_git_folder>/git/Kconfig 파일에서 사용 가능한 모든 구성을 볼 수 있다.

이러한 수정 사항으로 부트로더를 다시 컴파일하고 20단계와 같이 저장한다.

[이전] [목차] [다음]

AN13709 - Measurements

까마귀75 — Tue, 16 May 2023 09:19:45 +0900

[이전] [목차] [다음]

3 Measurements

측정 범위는 보드 POR(Power-On Reset)과 PSPLASH 프로세스 시작 사이로 간주된다.

다음 측정에 사용되는 설정은 Boot Time Measurements Methodology 문서에 설명되어 있다.

측정된 간격은 다음과 같다.

Table 1. Measured intervals

Time point	Interval between pulses	Location of the pulse	Boot stages
BootROM	nRST -> before ddr_init()	board/freescale/imx8mn_evk/spl.c/board_init_f()	SPL
DDR initialization	before ddr_init() -> after ddr_init()	board/freescale/imx8mn_evk/spl.c/board_init_f()
SPL initialization + Load U-Boot image	after ddr_init() -> before image_entry()	common/spl/spl.c/jump_to_image_no_args()
U-Boot initializations (init_sequence_f)	before image_entry() -> start init_sequence_r	common/board_r.c/board_init_r()	U-BOOT
U-Boot initializations (init_sequence_r)	start init_sequence_r -> u-boot main_loop	common/main.c
Boot sequence	u-boot main_loop -> before load_image	include/configs/imx8mn_evk.h
Kernel Image Load	before loadimage -> after loadimage	include/configs/imx8mn_evk.h
Kernel Boot Until PSPLASH Image	after loadimage -> psplash	psplash.c	Kernel

[이전] [목차] [다음]

AN13709 - General description

까마귀75 — Mon, 15 May 2023 13:55:45 +0900

[이전] [목차] [다음]

2 General description

이 섹션에서는 부팅 시간을 단축하기 위해 수행할 수 있는 일반적인 수정 방법에 대한 개요를 설명한다.

2.1 Reducing bootloader time

부트 지연 제거 : 최소한의 변경으로 기본 구성에 비해 약 2초가 절약된다. 이로 인해 U-Boot는 부팅 중 키 입력 단계를 건너뛴다.
Falcon Mode 구현 : 기본 구성에 비해 약 4초가 절약된다. 전체 U-Boot를 건너뛰고 커널을 직접 로드할 수 있는 U-Boot의 일부인 SPL(Second Program Loader)을 활성화한다.

2.2 Reducing Linux kernel boot time

콘솔 메세지 줄이기 : 약 3초가 절약된다. 커널 명령줄에 quiet를 추가한다.
드라이버와 파일 시스템을 제거하여 커널 슬림화 : 기본적으로 커널 이미지에는 보드에서 지원되는 대부분의 기능을 활성화하기 위해 많은 드라이버와 파일 시스템(예: UBIFS)이 포함되어 있다. 포함된 드라이버와 파일 시스템 목록은 사용 사례에 따라 다듬을 수 있다.

2.3 Reducing user-space boot time

Systemd 스크립트 초기화에서 실행 순서 변경 : 약 600ms를 절약한다. 종속성을 고려하여, 가능한 한 빨리 PSPLASH 프로세스를 시작한다.

[이전] [목차] [다음]

AN13709 - Introduction

까마귀75 — Mon, 15 May 2023 13:01:06 +0900

[이전] [목차] [다음]

1 Introduction

이 문서는 i.MX8M Nano 보드의 Linux 부팅 시간을 줄이는 방법을 안내한다.

참고:
동일한 워크플로가 전체 i.MX8M 제품군에 적용되지만, 각 SoC에 대한 특정 코드의 업데이트가 필요할 수 있다.

이 문서의 목적은 다음과 같다.

기본 부팅 시간 측정과 평가
Bootloader 최적화
Linux Kernel와 User Space 최적화

1.1 Software environment

Linux BSP 릴리스 5.10.72-2.2.0이 최적화 프로세스에 사용된다. imx-image-core Yocto 이미지는 실험 중에 사용된다.

1.2 Hardware setup and equipment

NXP i.MX 8MN EVK LPDDR4 개발 키트
Micro SD 카드: SanDisk Ultra 32GB Micro SDHC I Class 10이 실험에 사용되었다.
디버그 포트용 Micro-USB
시간 측정을 위한 최소 요구 사항은 4채널 10MS/s의 로직 분석기이다. Saleae Logic 8이 실험에 사용되었다.

[이전] [목차] [다음]

Linux Boot Time Optimizations for i.MX8M Family (AN13709)

까마귀75 — Mon, 15 May 2023 12:54:14 +0900

문서 정보

Information	Content
Keywords	i.MX8MN, Reduce Boot Time, Linux, Falcon Mode
Abstract	이 문서는 i.MX8M Nano 보드의 Linux 부팅 시간을 줄이는 방법을 안내한다.

Rev. 0 — 18 August 2022

목차 (Contents)

Introduction
1. 1 Software environment
2. 2 Hardware setup and equipment
General description
Measurements
Bootloader optimizations
Kernel space optimizations
1. 1 Adding quiet
2. 2 Removing unnecessary drivers and file systems
User space optimizations
Results
References
~~Revision history~~

i.MX 8M Plus 개발 환경 구축 - Yocto Command 정리

까마귀75 — Wed, 3 May 2023 10:15:40 +0900

[이전] [목차] [다음]

Yocto Command 정리

imx8mp-evk에서 자주 사용되는 Yocto Command를 설명한다.

이미지 빌드 구성

i.MX 머신 설정을 단순화하는 imx-setup-release.sh 스크립트를 제공한다. 스크립트 사용시, 빌드할 머신의 이름과 그래픽 백엔드를 지정해야 한다. 스크립트는 지정된 머신과 그래픽 백엔드를 위한 디렉터리와 구성 파일을 설정한다.

참고:
자세한 내용은 i.MX Yocto Project User`s Guide - Image Build를 참조한다.

imx-setup-release.sh의 사용 문법은 다음과 같다.

$ DISTRO=<distro-name> MACHINE=<machine-name> source imx-setup-release.sh -b <build-dir>

DISTRO는 "배포"를 의미하며 여기서는 그래픽 백엔드를 지정한다. 그래픽 백엔드는 아래와 같이 3가지를 지정할 수 있으나, imx8mp-evk에서는 fsl-imx-fb를 지원하지 않는다.

fsl-imx-wayland : Wayland weston 그래픽
fsl-imx-xwayland : Wayland 그래픽과 X11 (EGL 사용 X11 애플리케이션은 지원 안됨)
fsl-imx-fb : 프레임 버퍼 그래픽

fsl-imx-fb는 X11이나 Wayland가 아닌 단순 프레임 버퍼용 그래픽이다.

imx8mp-evk에서는 사용자의 환경에 맞게 fsl-imx-wayland나 fsl-imx-xwayland를 지정하면 된다. 해당 구성 파일은 아래의 경로에서 찾을 수 있다(<project-dir>은 "repo init"를 수행한 디렉터리이다.).

<project-dir>/sources/meta-imx/meta-sdk/conf/distro/

해당 디렉터리에는 "include" 디렉터리와 fsl-imx-fb.conf, fsl-imx-wayland.conf, fsl-imx-x11.conf, fsl-imx-xwayland.conf 파일들이 있다. 이 중 fsl-imx-x11.conf는 더 이상 지원하지 않는다.

MACHINE에는 사용할 머신 구성 파일을 지정한다. imx8mp-evk 사용시 imx8mp-lpddr4-evk를 지정하면 된다. 사용가능한 머신 구성 파일은 아래의 경로에서 찾을 수 있다.

<project-dir>/sources/meta-freescale/conf/machine/
또는
<project-dir>/sources/meta-imx/meta-bsp/conf/machine/

참고:
meta-imx 레이어는 meta-freescale 레이어를 기반으로 새로 추가되거나 업데이트되는 머신 구성을 제공한다(meta-imx는 meta-freescale를 오버레이한다).

"-b <build-dir>"은 imx-setup-release.sh 스크립트에 의해 생성되는 빌드 디렉터리의 이름을 지정한다.

imx-setup-release.sh 스크립트가 처음 실행이 되면, EULA 사용권 동의 메세지가 표시된다. EULA 사용권에 동의하면 <build-dir>/conf/ 디렉터리 안 local.conf 파일에 아래와 같은 사용권 동의에 대한 정보가 저장되고 더 이상 EULA 사용권 동의 메세지가 출력되지 않는다.

#	지정한 머신 정보
MACHINE ??= 'imx8mp-lpddr4-evk'
#	지정한 그래픽 백엔드 정보
DISTRO ?= 'fsl-imx-wayland'
...
#	EULA 사용권 동의
ACCEPT_FSL_EULA = "1"
...

-b 옵션으로 지정된 <build-dir>이 작업 디렉터리이다. <build-dir>/conf/ 폴더에 bblayers.conf, local.conf 등의 파일이 생성된다. bblayers.conf에는 사용되는 메타레이어가 포함되어 있다. 사용자 정의 레이어 추가시 bblayers.conf 파일에 아래와 같이 경로를 추가한다.

LCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"
...
# 마지막 라인에 추가한다.
BBLAYERS += "${BSPDIR}/sources/<custom-layer>"

이미지 빌드

이미지 빌드시 아래의 커맨드를 사용한다.

//	지정한 <target>로 이미지를 빌드한다.
$ bitbake <target>

지정 가능한 <target>는 아래와 같다.

imx-image-core : Wayland 백엔드에 사용할 테스트 애플리케이션이 있는 이미지 생성
imx-image-multimedia : Qt 콘텐츠가 없는 GUI로 이미지 생성
imx-image-full : 머신 러닝 기능이 포함된 오픈 소스 Qt 이미지를 생성

처음 이미지 빌드시 필요한 패키지를 다운로드하고 빌드하기 때문에 시간이 많이 소요된다.

SDK 빌드

지정한 <target>에 해당하는 SDK를 빌드하는 커맨드는 아래와 같다.

$ DISTRO=<distro-name> MACHINE=<machine-name> bitbake <target> -c populate_sdk

<distro-name>, <machine-name>, <target>은 위에서 설명한 값으로 설정한다.

SDK는 <project-dir>/<build-dir>/tmp/deploy/sdk 디렉터리에 확장자가 .sh로 생성된다. 사용할 Host PC로 파일을 복사하고 설치하면 된다. 기본 설치 경로는 /opt/<distro-name>/<kernel-ver>-<yocto-ver>/environment-setup-armv8a-poky-linux 이다. <kernel-ver>은 커널 버전을 나타내고, <yocto-ver>은 Yocto Project 버전을 나타낸다.

SDK 환경 설정을 위해 아래의 커맨드를 사용한다.

//	SDK 환경 설정을 한다.
$ source /opt/<distro-name>/<kernel-ver>-<yocto-ver>/environment-setup-armv8a-poky-linux
$ export ARCH=arm64

U-Boot 관련

u-boot 코드를 수정한 후 컴파일하고 imx-boot를 만드는 커맨드는 아래와 같다(순차적으로 실행한다).

$ MACHINE=<machine-name> bitbake -f -c compile u-boot-imx
$ MACHINE=<machine-name> bitbake -f -c install u-boot-imx
$ MACHINE=<machine-name> bitbake -f -c deploy u-boot-imx

$ MACHINE=<machine-name> bitbake -f -c compile imx-boot
$ MACHINE=<machine-name> bitbake -f -c install imx-boot
$ MACHINE=<machine-name> bitbake -f -c deploy imx-boot

또는 아래와 같이 수행해도 된다.

$ MACHINE=<machine-name> bitbake -f -c compile u-boot-imx
$ MACHINE=<machine-name> bitbake u-boot-imx imx-boot

컴파일 중간 결과물을 삭제시에는 아래의 커맨드를 수행한다.

$ MACHINE=<machine-name> bitbake -f -c clean u-boot-imx

다운로드한 u-boot 소스를 삭제시에는 아래의 커맨드를 수행한다.

$ MACHINE=<machine-name> bitbake -f -c cleanall u-boot-imx

<machine-name>은 위에서 설명한 값으로 설정한다.

Kernel 관련

커널 소스를 수정 후 빌드하는 커맨드는 아래와 같다.

$ MACHINE=<machine-name> bitbake -f -c compile linux-imx
$ MACHINE=<machine-name> bitbake -f -c install linux-imx
$ MACHINE=<machine-name> bitbake -f -c deploy linux-imx

컴파일 중간 결과물을 삭제시에는 아래의 커맨드를 수행한다.

$ MACHINE=<machine-name> bitbake -f -c clean linux-imx

다운로드한 커널 소스를 삭제시에는 아래의 커맨드를 수행한다.

$ MACHINE=<machine-name> bitbake -f -c cleanall linux-imx

<machine-name>은 위에서 설명한 값으로 설정한다.

U-Boot, Kernel 소스 수정후 이미지 빌드

소스 수정후 이미지 빌드는 아래의 커맨드를 순차적으로 수행한다.

$ MACHINE=<machine-name> bitbake -f -c rootfs <target>
$ MACHINE=<machine-name> bitbake -f -c image_wic <target>
$ MACHINE=<machine-name> bitbake -f -c image_complete <target>

<machine-name>, <target>은 위에서 설명한 값으로 설정한다.

Recipe Dependency 그래프 생성

레시피에 대한 의존성 그래프를 생성하는 커맨드는 아래와 같다.

$ MACHINE=<machine-name> bitbake -g <recipe-name>

위의 커맨드를 실행하면, 해당 빌드 디렉토리에 "task-depens.dot" 파일이 생성된다.

이 파일을 아래의 커맨드를 사용하여 PDF 문서로 만들 수 있다.

$ dot -Tpdf task-depends.dot -o outfile.pdf

dot 프로그램이 설치되어 있지 않으면, 아래의 커맨드를 수행해 설치를 한다.

$ sudo apt-get install graphviz

아래의 커맨드를 수행하면 GUI 윈도우에서 레시피의 의존성을 볼 수 있다.

$ MACHINE=<machine-name> bitbake -g -u taskexp <recipe-name>

Recipe에서 사용가능한 Task 출력

아래의 커맨드를 사용하여 레시피에서 지원하는 태스크를 출력할 수 있다.

$ MACHINE=<machine-name> bitbake -c listtasks <recipe-name>

아래의 커맨드로 해당 레시피에서 원하는 태스크 수행할 수 있다.

$ MACHINE=<machine-name> bitbake -c <task> <recipe-name>
또는 
$ MACHINE=<machine-name> bitbake -f -c <task> <recipe-name>

[이전] [목차] [다음]

i.MX 8M Plus 개발 환경 구축 - U-Boot 사용자 지정

까마귀75 — Tue, 2 May 2023 09:32:40 +0900

[이전] [목차] [다음]

U-Boot 사용자 지정

참고:
커널 사용자 지정에서 "repo 설정", "Yocto Project 설정"과 "빌드 구성"을 먼저 진행했다고 가정한다.
SDK를 설치한 상태라고 가정한다.

U-Boot 소스 코드 복사

아래의 단계에 따라 u-boot 소스 코드를 로컬 저장소로 복사한다. 기본 디렉터리는 "/<project-dir>/<build-dir>" 이다.

//	u-boot 소스 코드를 다운로드하여 압축을 푼다.
$ bitbake -c unpack virtual/bootloader

//	로컬 저장소를 생성한다.
$ mkdir -p ../local_repos/uboot-imx

//	u-boot 소스 코드를 로컬 저장소로 복사한다.
$ cp -a tmp/work/imx8mp_lpddr4_evk-poky-linux/u-boot-imx/2022.04-r0/git/. ../local_repos/uboot-imx

//	로컬 저장소로 이동한다.
$ cd ../local_repos/uboot-imx

//	가장 최근 commit으로 되돌리고, unstaged 상태의 변경 사항을 모두 제거한다.
$ git reset --hard

//	untracked(추적되지 않는) 파일(디렉터리)을 삭제한다.
$ git clean -fdx

"/local_repos/uboot-imx/"에서 u-boot와 관련된 수정 작업을 진행한다.

U-Boot 구성 변경

"/local_repos/uboot-imx/"에서 다음을 실행하여 사용자 지정 defconfig를 생성한다.

//	구성 이전으로 되돌린다(소스 코드 압축 해제 후 상태로...).
$ make distclean

//	구성을 설정한다.
$ make imx8mp_evk_defconfig

//	u-boot 메뉴 구성을 실행한다.
$ make menuconfig

구성 메뉴에서 사용하거나 해제할 u-boot 기능을 선택하여 수정한 후, 새로운 구성을 저장한다.

다음을 수행하여 업데이트된 defconfig를 적용한다.

//	defconfig를 저장한다.
$ make savedefconfig

//	원본 defconfig를 다른 파일명으로 변경한다.
$ cp configs/imx8mp_evk_defconfig configs/imx8mp_evk_defconfig.orig

//	사용할 defconfig를 저장한다.
$ cp defconfig configs/imx8mp_evk_defconfig

//	구성 이전으로 되돌린다.
$ make distclean

//	구성을 설정한다.
$ make imx8mp_evk_defconfig

참고:
u-boot console 기본 속도를 변경하려면, defconfig 파일에 "CONFIG_BAUDRATE=baudrate"를 추가해야 한다. 보드 구성 헤더 파일(/include/configs/imx8mp_evk.h)에 추가하면 변경이 되지 않는다.

U-Boot 패치 파일 생성

"/local_repos/uboot-imx/"에서 필요한 소스를 수정한다.

다음을 수행하여 패치 파일을 생성한다.

//	패치 파일을 생성한다.
$ git diff > <custom-name>.patch

커널 사용자 지정에서 만든 사용자 지정 레이어에 다음을 수행한다.

//	프로젝트 디렉터리로 이동한다.
$ cd <project-dir>

//	u-boot 패치 관련 디렉터리를 생성한다.
$ make -p sources/<custom-layer>/recipes-bsp/u-boot/u-boot-imx/fsl

"sources/<custom-layer>/recipes-bsp/u-boot" 디렉터리에 "u-boot-imx_2022.04.bbappend" 파일을 생성하고 아래의 내용을 작성한다.

# Copyright
# Released under the MIT license (see COPYING.MIT for the terms)
#
# SPDX-License-Identifier: MIT
#

FILESEXTRAPATHS:prepend := "${BSPDIR}/sources/<custom-layer>/recipes-bsp/u-boot/${PN}:"
SRC_URI += "file://u-boot.patch"

생성된 패치 파일을 "sources/<custom-layer>/recipes-bsp/u-boot/u-boot-imx/fsl" 디렉터리에 "u-boot.patch" 이름으로 복사한다.

//	패치 파일을 복사한다.
cp local_repos/uboot-imx/<custom-name>.patch sources/<custom-layer>/recipes-bsp/u-boot/u-boot-imx/fsl/u-boot.patch

다음 커맨드로 u-boot를 빌드한다.

//	u-boot를 빌드한다.
$ MACHIONE=<custom-layer> bitbake imx-boot

빌드 후 바이너리 파일은 "tmp/deploy/images/<custom-layer>/imx-boot-<custom-layer>-sd.bin-flash_evk"에 생성된다.

[이전] [목차] [다음]

i.MX 8M Plus 개발 환경 구축 - 커널 사용자 지정

까마귀75 — Mon, 24 Apr 2023 12:39:22 +0900

[이전] [목차] [다음]

커널 사용자 지정

커널 구성

Yocto Project에서 사용하는 기본 커널 구성 파일은 커널 소스 트리의 일부로 아래 위치에 있다(Yocto Project에서 커널 위치는 <build-dir>/tmp/work-shared/imx8mp-lpddr4-evk/kernel-source/ 이다.).

arch/arm64/configs/imx_v8_defconfig

커널을 구성하기 전에 Yocto Project 작업 순서는 다음과 같다.

repo 설정

//	bin 폴더가 있는 경우, 아래 단계는 생략한다.
$ mkdir ~/bin
//	repo를 다운로드 받는다.
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
//	repo의 실행 권한을 설정한다.
$ chmod a+x ~/bin/repo
//	.bashrc 파일에 ~/bin 경로를 PATH 환경 변수에 추가한다.
export PATH=~/bin:$PATH

Yocto Project 설정

git 설정

//	git를 설정한다.
$ git config --global user.name "Your Name"
$ git config --global user.email "Your Email"
//	설정 내용을 확인한다.
$ git config --list

Yocto Project 설정

//	디렉터리를 생성한다.
$ mkdir <project-dir>
//	생성한 디렉터리로 이동한다.
$ cd <project-dir>
//	repo를 사용하여 초기화한다(버전에 맞게 설정한다).
$ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-langdale -m imx-6.1.1-1.0.0.xml
또는
$ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-kirkstone -m imx-5.15.52-2.1.0.xml
//	repo를 동기화한다.
$ repo sync

빌드 구성

//	빌드 구성을 진행한다(<build-dir>에 원하는 빌드 디렉터리를 설정한다).
$ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b <build-dir>

커널 구성

커널 menuconfig를 실행하여 필요한 작업을 진행한다(작업을 완료한 후, 저장하고 menuconfig에서 나온다).

//	커널 menuconfig 실행
$ bitbake linux-imx -c menuconfig
또는
$ bitbake -c menuconfig virtual/kernel

.config 커널 구성 파일은 <build-dir>/tmp/work/imx8mp_lpddr4_evk-poky-linux/linux-imx/6.1.y+gitAUTOINC+29549c7073-r0/build/.config에 저장된다(사용하는 커널 버전에 따라 "6.1.y+gitAUTOINC+29549c7073-r0" 디렉터리만 달라진다).

이 시점에서 "bitbake imx-image-full" 커맨드를 사용하여 이미지를 빌드하거나 "bitbake virtual/kernel"이나 "bitbake linux-imx" 커맨드를 사용하여 커널을 빌드할 수 있다. 또는 변경 사항을 영구적으로 적용하기 위해 다음 단계를 수행할 수 있다.

변경된 커널 구성 영구 적용

//	.config를 defconfig에 적용한다.
$ bitbake -c savedefconfig virtual/kernel
또는
$ bitbake -c savedefconfig linux-imx

.config 커널 구성 파일이 있는 디렉터리에 defconfig 파일이 생성된다.

이 구성을 영구적으로 사용하려면,

defconfig 파일을 arch/arm64/configs/imx_v8_defconfig 파일에 덮어쓴다(overwrite 한다).
커널 레시피에서 소스 트리 외부의 defconfig를 사용하도록 설정한다(커스텀 레이어 사용).

커스텀 레이어 생성 (사용자 정의 defconfig 적용)

참고:
IMXBSPPG와 IMXLXYOCTOUG 문서의 내용으로 커스텀 레이어를 생성하여 사용자 정의 defconfig 파일을 적용하면 imx8mpevk에서는 적용이 안되는 문제가 있다. 그래서 아래의 내용은 직접 찾은 방법을 설명한다.

커스텀 레이어를 생성한다(현재 <build-dir>에 위치한다고 가정한다).

//	커스텀 레이어 생성 (기본 샘플 레이어가 생성된다.)
$ bitbake-layers create-layer ../sources/<custom-layer>

/sources/<custom-layer>/conf/layer.conf 파일의 내용을 아래와 같이 수정한다.

# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
            ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "meta-thermal"
BBFILE_PATTERN_meta-thermal = "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-thermal = "6"

LAYERDEPENDS_meta-thermal = "core"
LAYERSERIES_COMPAT_meta-thermal = "kirkstone langdale"

# 꼭 추가해야 한다(사용할 리눅스를 설정).
PREFERRED_PROVIDER_virtual/kernel_thermal = "linux-imx"

/sources/<custom-layer>/conf/machine 디렉터리를 생성하고, /sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf 파일을 /sources/<custom-layer>/conf/machine/<custom-name>.conf로 복사한다.

<build-dir>/conf/bblayers.conf 파일에 <custom-layer>를 아래와 같이 추가한다.

BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-poky \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  ${BSPDIR}/sources/meta-openembedded/meta-python \
  \
  ${BSPDIR}/sources/meta-freescale \
  ${BSPDIR}/sources/meta-freescale-3rdparty \
  ${BSPDIR}/sources/meta-freescale-distro \
  ${BSPDIR}/sources/<custom-layer> \
"

/sources/<custom-layer>/recipes-kernel/linux/linux-imx 디렉터리를 생성한다.

// -p 옵션을 주면 하위 디렉터리까지 순차적으로 생성된다.
$ mkdir -p /sources/<custom-layer>/recipes-kernel/linux/linux-imx

defconfig 파일을 복사한다(사용하는 커널 버전에 따라 6.1.y+gitAUTOINC+29549c7073-r0 디렉터리는 변경될 수 있다).

//	커널 레시피가 있는 디렉터리로 이동한다.
$ cd ~/<project-dir>/sources/<custom-layer>/recipes-kernel/linux

//	defconfig 파일을 linux-imx 디렉터리에 복사한다.
$ cp ~/<project-dir>/<build-dir>/tmp/work/imx8mp_lpddr4_evk-poky-linux/linux-imx/6.1.y+gitAUTOINC+29549c7073-r0/build/defconfig linux-imx/defconfig

~/<project-dir>/sources/<custom-layer>/recipes-kernel/linux 디렉터리에 linux-imx_6.1.bbappend 파일을 생성하여 아래의 내용을 추가한다(사용하는 커널 버전에 따라 파일 이름이 변경될 수 있다).

# Copyright
# Released under the MIT license (see COPYING.MIT for the terms)
#
# SPDX-License-Identifier: MIT
#

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

# 현재 디렉터리를 얻어오는 방법이 없어서 ${THISDIR}를 기준으로 작업 디렉터리를 설정한다.
CUSTOM_KERNEL_DIR = "${THISDIR}/../../../../<custom-layer>/recipes-kernel/linux/${PN}"
CUSTOM_KERNEL_CONFIG_AARCH64 = "defconfig"

addtask pre_copy_defconfig after do_kernel_configme before do_copy_defconfig
do_pre_copy_defconfig () {
	if [ ${DO_CONFIG_V7_COPY:mx8-nxp-bsp} = "no" ]; then
        # defconfig를 커널 구성에 사용하기 위해 파일을 복사한다.
        mkdir -p ${B}
        cp ${CUSTOM_KERNEL_DIR}/${CUSTOM_KERNEL_CONFIG_AARCH64} ${S}/arch/arm64/configs/${IMX_KERNEL_CONFIG_AARCH64}
    fi
}

"bitbake -c cleanall linux-imx"을 먼저 실행하여 정리한다.

"MACHINE=<custom-layer> bitbake virtual/kernel"이나 "MACHINE=<custom-layer> bitbake linux-imx"를 실행하여 커스텀 defconfig가 적용이 되는지 확인한다. 확인 방법은 <build-dir>/tmp/work/<custom-layer>-poky-linux/linux-imx/6.1.y+gitAUTOINC+29549c7073-r0/defconfig 파일이 사용자 지정 defconfig 파일과 내용이 같은지 확인한다.

6.1.y+gitAUTOINC+29549c7073-r0 디렉터리는 커널 버전에 따라 변경될 수 있다.

커스텀 레이어 (커널 소스 패치 파일 적용)

참고:
커널 소스 패치 적용에 대한 자세한 내용은 다음 사이트를 참고한다.
Yocto_Customizing_the_Linux_kernel
위 사이트 3가지 방법 중 첫 번째 방법을 적용하는 방법을 설명한다.

먼저 "MACHINE=<custom-layer> bitbake virtual/kernel"이나 "MACHINE=<custom-layer> bitbake linux-imx"를 실행하여 완료한 후라고 가정한다. 현재 디렉터리 위치는 <build-dir> 이다.

//	패치 파일을 찾아 소스코드에 적용한다.
$ MACHINE=<custom-layer> bitbake -c patch virtual/kernel
또는
$ MACHINE=<custom-layer> bitbake -c patch linux-imx

//	커널 소스를 저장할 로컬 저장소 생성(-p 옵션으로 하위 디렉터리까지 생성)한다.
//	로컬 저장소는 <project-dir> 아래 생성된다.
$ mkdir -p ../local_repos/linux-imx

//	커널 소스를 로컬 저장소로 복사한다.
$ cp -a tmp/work-shared/<custom-layer>/kernel-source/. ../local_repos/linux-imx

//	로컬 저장소로 이동한다.
$ cd ../local_repos/linux-imx

//	가장 최근 commit으로 되돌리고, unstaged 상태의 변경 사항을 모두 제거한다.
$ git reset --hard

//	untracked(추적되지 않는) 파일(디렉터리)을 삭제한다.
$ git clean -fdx

"local_repos/linux-imx"에서 커널 소스와 관련된 수정 작업을 진행한다.

작업이 완료되면 패치 파일을 생성한다.

//	git로 패치 파일을 생성한다.
$ git diff > <custom-name>.patch

"local_repos/linux-imx/<custom-name>.patch" 파일이 생성될 것이다. 해당 파일을 "<project-dir>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx" 디렉터리에 복사한다.

위에서 작업한 "linux-imx_6.1.bbappend" 파일의 내용을 아래와 같이 수정한다.

# Copyright
# Released under the MIT license (see COPYING.MIT for the terms)
#
# SPDX-License-Identifier: MIT
#

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://<custom-name>.patch"

# 현재 디렉터리를 얻어오는 방법이 없어서 ${THISDIR}를 기준으로 작업 디렉터리를 설정한다.
CUSTOM_KERNEL_DIR = "${THISDIR}/../../../../<custom-layer>/recipes-kernel/linux/${PN}"
CUSTOM_KERNEL_CONFIG_AARCH64 = "defconfig"

addtask pre_copy_defconfig after do_kernel_configme before do_copy_defconfig
do_pre_copy_defconfig () {
	if [ ${DO_CONFIG_V7_COPY:mx8-nxp-bsp} = "no" ]; then
        # defconfig를 커널 구성에 사용하기 위해 파일을 복사한다.
        mkdir -p ${B}
        cp ${CUSTOM_KERNEL_DIR}/${CUSTOM_KERNEL_CONFIG_AARCH64} ${S}/arch/arm64/configs/${IMX_KERNEL_CONFIG_AARCH64}
    fi
}

"MACHINE=<custom-layer> bitbake -c cleanall linux-imx"를 사용하여 정리한다.

"MACHINE=<custom-layer> bitbake virtual/kernel"이나 "MACHINE=<custom-layer> bitbake linux-imx"를 사용하여 빌드를 진행한다.

[이전] [목차] [다음]

i.MX 8M Series MIPI Capture System(AN13857) - Revision history

까마귀75 — Tue, 11 Apr 2023 14:23:49 +0900

[이전] [목차] [다음]

9 Revision history

Table 44. Revision history

Revision number	Date	Substantive changes
0	15 March 2023	릴리스 개시

[이전] [목차] [다음]

i.MX 8M Series MIPI Capture System(AN13857) - Interlaced sensor support and De-interlacing

까마귀75 — Tue, 11 Apr 2023 14:14:39 +0900

[이전] [목차] [다음]

8 Interlaced sensor support and De-interlacing

모든 i.MX 8M 시리즈 프로세서는 인터레이스 MIPI 카메라를 지원할 수 있다. 단, i.MX 8MN과 i.MX 8MP에서만 하드웨어 디인터레이싱 기능을 지원할 수 있다.

사용 사례 예제:

센서에서 인터레이스된 odd/even 프레임(720x288, yuv422)을 출력한다.

사용자는 이 사용 사례에 대해 ISI weaving 디인터레이싱을 활성화하는 방법에 대해 다음 단계를 참조할 수 있다.

720x288, yuv422 프레임 수신 방법은 Section 6.2와 Section 6.3을 참조한다.
GASKET_x_CTRL[GASKET_x_INTER_MODE] 필드를 01b로 구성한다.
CHNL_IMG_CTRL[DEINT] 필드를 10b 또는 11b로 구성하면, 디인터레이스 프레임이 FRM_STRD 인터럽트 두 번마다 메모리에 저장된다.

[이전] [목차] [다음]

i.MX 8M Series MIPI Capture System(AN13857) - Embedded data support

까마귀75 — Tue, 11 Apr 2023 12:42:18 +0900

[이전] [목차] [다음]

7 Embedded data support

일부 카메라 센서는 이미지 데이터와 함께 임베디드된 데이터를 보낼 수 있다. Figure 6에서 볼 수 있듯이, 임베디드된 데이터는 프레임의 시작이나 끝에 포함된다.

Figure 6. Structure with Embedded Data at the Beginning and End of the Frame

MIPI CSI-2 사양에 따르면, 임베디드된 데이터의 데이터 유형은 이미지 데이터 유형(0x18에서 0x3F까지)과 다른 0x12여야 한다. 이 경우, 카메라 스트림에는 인터리빙 모드의 데이터 유형으로 정의되는 여러 유형의 데이터가 포함된다. 그러나 8M 시리즈 캡처 시스템은 인터리빙 모드의 데이터 유형을 지원할 수 없다.

사용 사례 예제:

센서에서 이미지 프레임(640x480, RAW12)과 프레임 시작 부분에 2라인이 임베디된 데이터를 출력한다.

위의 사용 사례를 지원하려면, 해결 방법으로 사용자는 다음을 수행해야 한다:

이미지 데이터 유형(RAW12: 0x2C)으로 임베디드된 데이터를 출력하도록 센서를 구성한다.
이미지 픽셀과 정렬되도록 각 임베디드된 데이터에 대해 0을 추가하도록 센서를 구성한다(12비트 정렬, {embedded data, 4b’0}).
그러면 이 센서의 총 출력은 RAW12 데이터의 640x482 크기로 간주할 수 있다. 사용자는 이 경우를 지원하도록 Rx 캡처 시스템을 구성하는 방법에 대한 자세한 내용을 Section 6.2와 Section 6.3에서 참조할 수 있다.

참고:
센서가 0x12 데이터 유형의 임베디드된 데이터만 보낼 수 있는 경우, i.MX 8M 시리즈 프로세서에서 지원할 수 없다.

[이전] [목차] [다음]

i.MX 8M Series MIPI Capture System(AN13857) - Porting new camera

까마귀75 — Tue, 11 Apr 2023 10:06:28 +0900

[이전] [목차] [다음]

6 Porting new camera

이 섹션에서는 i.MX 8M 시리즈 프로세서에 새로운 카메라를 포팅하는 방법을 설명한다. i.MX 8M 시리즈 MIPI 캡처 시스템을 구성하는 방법을 보여주기 위해 AR0144(1280x800@60fps, RAW12, 2 레인, 레인당 445.5 Mbps)를 예로 들었다.

참고:
기본 BSP 릴리스를 통하여, 8M 시리즈 MIPI 캡처 시스템은 YUV422 형식 카메라 입력만 지원할 수 있다. 이 섹션에서는 RAW8, RAW10, RAW12, RGB565, RGB888과 같은 다른 형식의 카메라 입력을 지원하는 방법을 보여준다.

6.1 Sensor initialization

사용자는 다음 단계를 통해 센서가 제대로 작동하는지 확인해야 한다:

모든 공급 전압을 확인한다.
센서의 MCLK 주파수를 확인한다.
리셋과 파워 시퀀스를 확인한다.
센서와 SoC 사이의 I2C 통신이 작동하는지 확인한다.
센서 초기화 레지스터가 올바르게 구성되었는지 확인한다.
센서 데이터 레인과 클럭 레인 신호를 확인한다.
센서 출력 스트림이 SoC MIPI 캡처 기능 내에 있는지 확인한다(Section 5 참조).

6.2 MIPI CSI-2 Rx subsystem configuration

기본적으로 사용자는 센서 출력에 따라 i.MX 8M 시리즈 MIPI CSI-2 Rx 서브시스템을 구성해야 한다. 이러한 모든 구성은 Linux dts와 MIPI CSI-2 드라이버에서 수행할 수 있다. 그리고 사용자는 관련 레지스터 필드의 값을 읽어 이러한 파라미터가 올바르게 구성되었는지 확인할 수 있다(Section 3.1.6과 Section 3.2.6, “Register Definition” 참조).

▶ CSI-2 DPHY에서 데이터 레인 수를 구성한다.

Table 38. The number of data lanes in CSI-2 DPHY

SoC	Register	Field	Value
i.MX 8MQ	CSI2RX_CFG_NUM_LANES	1-0 csi2rx_cfg_num_lanes	01b
i.MX 8MQ	CSI2RX_CFG_DISABLE_DATA_LANES	3-0 csi2rx_cfg_disable_data_lanes	1100b
i.MX 8MM i.MX 8MN i.MX 8MP	MIPI_CSIx_CSIS_COMMON_CTRL	9-8 LANE_NUMBER	01b
i.MX 8MM i.MX 8MN i.MX 8MP	MIPI_CSIx_DPHY_COMMON_CTRL	4-1 ENABLE_DAT	0011b

참고:
이 섹션에서 모든 테이블의 "value" 열은 AR0144에 대한 레퍼런스 설정을 보여준다.

▶ 센서의 데이터 속도에 따라 CSI-2 DPHY에서 high-speed settle timer를 구성한다(Section 3.1.5와 Section 3.2.5, “DPHY High-Speed Settle Timer” 참조).

Table 39. High-speed settle timer in CSI-2 DPHY according to the data rate of sensor

SoC	Register	Field	Value
i.MX 8MQ	IOMUXC_GPR_GPR34/41	7–2 CSI2_x_S_PRG_RXHS_SETTLE	0x6
i.MX 8MM i.MX 8MN i.MX 8MP	MIPI_CSIx_DPHY_COMMON_CTRL	31-24 HSSETTLE	0x9

▶ CSI-2 컨트롤러에서 이미지 데이터 유형, 수직/수평 이미지 해상도를 구성한(i.MX 8MM, i.MX 8MN, i.MX 8MP에만 해당).

Table 40. The image data type, vertical/horizontal image resolution in CSI-2 controller

SoC	Register	Field	Value
i.MX 8MM i.MX 8MN i.MX 8MP	MIPI_CSIx_ISP_CONFIG0	7–2 DATAFORMAT	0x2C
	MIPI_CSIx_ISP_RESOLUTION0	31-16 VRESOL	0x320
	MIPI_CSIx_ISP_RESOLUTION0	15-0 HRESOL	0x500

▶ Gasket에서 이미지 데이터 유형, 수직/수평 이미지 해상도를 구성한다(i.MX 8MN, i.MX 8MP에만 해당).

Table 41. The image data type, vertical/horizontal image resolution in Gasket

SoC	Register	Field	Value
i.MX 8MN i.MX 8MP	GASKET_x_CTRL	13-8 GASKET_x_DATA_TYPE	0x2C
	GASKET_x_HSIZE	31-0 GASKET_x_HSIZE	0x500
	GASKET_x_VSIZE	31-0 GASKET_x_VSIZE	0x320

6.3 Imaging subsystem configuration

또한 사용자는 센서 출력, 특히 형식과 이미지 크기 관련 레지스터 필드에 따라 i.MX 8M 시리즈 이미징 서브시스템을 구성해야 한다.

6.3.1 i.MX 8MQ/i.MX 8MM CSI bridge configuration

RAW, RGB 또는 YUV 형식 카메라 입력을 지원하려면 다음 CSI Bridge 레지스터 필드를 올바르게 구성해야 한다.

CSI_CR3[SENSOR_16BITS]
CSI_CR18[PARALLEL24_EN]
CSI_CR18[MIPI_DATA_FORMAT]

Table 42는 RAW, RGB, YUV 형식의 센서를 지원하도록 CSI Bridge를 구성하는 방법을 보여준다.

Table 42. CSI Bridge configuration for RAW, RGB, and YUV format sensor

Sensor Format	CSI_CR3 [SENSOR_16BITS]	CSI_CR18 [PARALLEL24_EN]	CSI_CR18 [MIPI_DATA_FORMAT]
RAW8	0	0	0x2A
RAW10	1	0	0x2B
RAW12	1	0	0x2C
RGB565	1	0	0x22
RGB888	1	1	0x24
YUV422	1	0	0x1E

참고:
YUV422 형식 지원과 관련하여 i.MX 8MQ와 i.MX 8MM 사이에는 약간의 차이가 있다. i.MX 8MQ에서 YUV422 형식 센서의 경우, CSI_CR3[SENSOR_16BITS]를 1로 설정해야 한다. i.MX 8MM에서 YUV422 형식 센서의 경우, CSI_CR3[SENSOR_16BITS]를 0(단일 픽셀 모드) 또는 1(듀얼 픽셀 모드)로 설정할 수 있다. YUV422 형식의 듀얼 픽셀 모드를 지원하려면, CSI_CR18[MIPI_DOUBLE_CMPNT]를 1로 설정하고 MIPI_CSIx_ISP_CONFIG0[PIXEL_MODE]를 01b로 설정해야 한다.

또한, CSI_IMAG_PARA[IMAGE_WIDTH, IMAGE_HEIGHT] 필드는 활성 센서 출력 크기에 따라 올바르게 구성되어야 한다.

6.3.2 i.MX 8MN/i.MX 8MP ISI configuration

RGB 또는 YUV 형식 입력의 경우, ISI 블럭은 형식 변환(예: YUV422에서 YUV420으로)과 색 공간 변환(예: RGB에서 YUV로)을 지원할 수 있다. 그러나 RAW 형식 입력의 경우 픽셀 변경 없이 메모리에 복사된다.

ISI 출력 형식은 CHNL_IMG_CTRL[FORMAT]에서 구성되며, Table 43은 RAW, RGB, YUV 형식 센서를 지원하도록 ISI를 구성하는 방법을 보여준다.

Table 43. ISI configuration for RAW, RGB, and YUV format sensor

	Sensor Format	CHNL_IMG_CTRL[FORMAT]
No processing	RAW10	001100b - RAW10
	RGB888	000110b - RGB888P
	YUV422	100000b - YUV422_1P8P
Format Conversion	YUV422	110001b - YUV420_2P8P
Color Space Conversion	YUV422	000110b - RGB888P
Color Space Conversion	RGB565	100000b - YUV422_1P8P

참고:
프로세싱하지 않는 경우, CHNL_IMG_CTRL[FORMAT]은 입력 카메라 센서와 동일한 형식으로 설정해야 한다. 형식 변환과 색 공간 변환 사례의 경우, Table 43에 레퍼런스 ISI 설정이 나열되어 있다. 더 많은 출력 형식이 지원될 수 있다. Section 4.2, “Register Definition”의 CHNL_IMG_CTRL[FORMAT] 필드 설명을 참조한다.

또한, CHNL_IMG_CFG[HEIGHT, WIDTH] 필드는 활성 센서 출력 크기에 따라 올바르게 구성되어야 한다.

6.4 Debug tips

8M 시리즈 프로세서에 새로운 카메라를 포팅할 때, 사용자는 캡처 중단 문제를 마주칠 수 있다. 즉, 센서 데이터를 메모리에 저장할 수 없다. 사용자는 아래 단계에 따라 이 문제를 디버깅할 수 있다.

MIPI CSI-2 Rx 서브시스템의 인터럽트 상태 확인
- i.MX 8MQ의 경우, CSI2RX_IRQ_STATUS 레지스터 확인
  - DPHY ErrSotHS 및/또는 ErrSotSync_HS 오류가 트리거되면, hs_settle이 올바르게 구성되었는지 확인한다.
  - 다른 오류가 트리거되면, 카메라 스트림이 안정적이고 MIPI 사양을 준수하는지 확인한다.
- i.MX 8MM/i.MX 8MN/i.MX 8MP의 경우, MIPI_CSIx_DPHY_STATUS와 MIPI_CSIx_INTERRUPT_SOURCE_0 레지스터 확인
  - 4레인 카메라가 연결된 경우, MIPI_CSIx_DPHY_STATUS[STOPSTATEDAT]는 0x0과 0xF 사이에서 변경되어야 한다.
  - 연결된 카메라가 비연속 클럭 모드에서 작동하는 경우, MIPI_CSIx_DPHY_STATUS [STOPSTATECLK]는 0과 1 사이에서 변경되어야 한다. 연결된 카메라가 연속 클럭 모드에서 작동하는 경우, 항상 0이어야 한다.
  - 데이터 레인이나 클럭 레인이 정지 상태나 ULPS 상태로 남아 있으면, 정상적으로 카메라가 잘 작동하지 않는 것이다. 센서 데이터 레인과 클럭 레인 신호를 확인하고 MIPI 사양을 준수하는지 확인한다.

참고:
i.MX 8MM, i.MX 8MN, i.MX 8MP는 Rx DPHY를 활성화하기 전에 연결된 카메라가 LP 상태에서 작동해야 한다. 그러나 카메라가 연속 클럭 모드에서 작동하는 경우, 클럭 레인은 항상 HS 모드에 있을 수 있다. 이 경우, Rx DPHY는 HS 모드를 감지하지 못하고 중지나 ULPS 상태로 잘못 유지될 수 있다.

MIPI_CSIx_INTERRUPT_SOURCE_0[ERR_SOT_HS]가 어설션되면, hs_settle이 올바르게 구성되었는지 확인한다.
MIPI_CSIx_INTERRUPT_SOURCE_0[ERR_OVER]가 어설션되면, 카메라 데이터 속도를 낮춘다.
MIPI_CSIx_INTERRUPT_SOURCE_0[FRAME_START/FRAME_END]가 어설션되지 않거나 다른 오류가 어설션되면, 센서가 안정적으로 작동하는지 확인한다.

Imaging 서브시스템의 인터럽트 상태를 확인한다.
- i.MX 8MQ, i.MX 8MM의 경우, CSI_SR 레지스터를 확인한다.
  - 캡처 파이프라인이 제대로 작동하는 경우, DMA_TSF_DONE_FB1와 DMA_TSF_DONE_FB2 인터럽트가 차례로 트리거되어야 하며 이러한 각 인터럽트 사이의 시간 간격은 입력 카메라 스트림의 프레임 간격과 동일해야 한다.
  - SOF_INT 및/또는 EOF_INT가 어설션되지 않으면, CSI Bridge가 MIPI CSI-2 Rx 서브시스템에서 데이터를 수신할 수 없다는 것을 의미한다. 카메라와 MIPI CSI-2 Rx 서브시스템이 올바르게 구성되었는지 확인한다.
  - BASEADDR_CHHANGE_ERROR가 여러 번 트리거되면, 일반적으로 CSI Bridge의 크기 및/또는 형식 관련 레지스터가 제대로 구성되지 않았다는 것을 나타낸다. 사용자는 CSI_CR18[BASEADDR_SWITCH_EN]에 0을 설정하여 이 인터럽트를 비활성화할 수 있다.
  - RF_OR_INT가 어설션되면, 카메라 데이터 속도를 낮춘다.

참고:
i.MX 8MQ의 경우, CSI Bridge Rx FIFO 오버플로로 인해 시스템 중단이 발생할 수 있는 알려진 문제가 있다. 자세한 내용과 해결 방법은 ERR050384를 확인한다.

i.MX 8MN, i.MX 8MP의 경우, CHNL_STS 레지스터를 확인한다.
- 캡처 파이프라인이 잘 작동하는 경우, BUF1_ACTIVE와 BUF2_ACTIVE 비트가 차례로 어설션되어야 한다. 그리고 각 FRM_STRD 인터럽트의 시간 간격은 카메라 입력 스트림의 프레임 간격과 동일해야 한다.
- LINE_STRD와 FRM_STRD가 어설션되지 않으면, ISI가 MIPI CSI-2 Rx 서브시스템에서 데이터를 수신할 수 없다는 것을 의미한다. 카메라와 MIPI CSI-2 Rx 서브시스템이 올바르게 구성되었는지 확인한다.
- OFLW_Y/U/V_BUF 오류가 어설션되면, 카메라 데이터 속도를 낮춘다.

[이전] [목차] [다음]

i.MX 8M Series MIPI Capture System(AN13857) - MIPI capture capabilities

까마귀75 — Mon, 10 Apr 2023 15:06:57 +0900

[이전] [목차] [다음]

5 MIPI capture capabilities

Table 37은 8M 시리즈 프로세서의 MIPI 캡처 기능을 보여준다.

Table 37. Bandwidth of i.MX 8M Series Capture System

SoC	Camera interface	Capture controller	Max total DPHY bandwidth	Max Rx pixel clock
i.MX 8MQ	2 x MIPI CSI-2 (4 lane each)	2 x CSI Bridge	각각 1.5 Gbps x 4	각각 333 MHz
i.MX 8MM	1 x MIPI CSI-2 (4 lane)	1 x CSI Bridge	1.5 Gbps x 4	333 MHz
i.MX 8MN	1 x MIPI CSI-2 (4 lane)	1 x ISI	1.5 Gbps x 4	333 MHz
i.MX 8MP	2 x MIPI CSI-2 (4 lane each)	2 x ISI	각각 1.5 Gbps x 4	CSI Port 1에서 싱글 카메라 500 MHz CSI Port 2에서 싱글 카메라 266 MHz 듀얼 카메라의 경우 각각 266 MHz

들어오는 카메라 데이터 속도와 픽셀 클럭은 Rx DPHY 대역폭과 픽셀 클럭보다 작거나 같아야 한다.

카메라 데이터 속도 ≤ Rx DPHY 대역폭
카메라 픽셀 클럭 ≤ Rx 픽셀 클럭

카메라 데이터 속도(bps)와 픽셀 클럭(Hz)은 다음과 같이 계산할 수 있다:

Pixel Clock = H_total * V _total * FPS

Data Rate = Pixel Clock* BPP

H_total = 총 라인 너비 (픽셀 단위) = active pixels + horizontal blanking pixels
V_total = 총 프레임 높이 (라인 단위) = active lines + vertical blanking lines
FPS = 초당 프레임 수
BPP = 픽셀당 비트 수

참고:
위의 대역폭 제한 외에도 ISI 블럭에는 추가 너비 제한이 있다(Section 4.2.3 참조). ERR011326와 ERR050384는 i.MX 8MQ MIPI 캡처 시스텀의 대역폭을 제한한다. i.MX 8MP에서 CSI-2 포트 1이 CSI-2 포트 2보다 대역폭이 더 크다는 사실에 주의해야 한다. 모든 i.MX 8M 시리즈 프로세서는 단일 MIPI CSI-2 인터페이스를 통해 동시에 전송되는 여러 카메라 스트림을 지원할 수 없다. 즉, i.MX 8M 시리즈 프로세서에서는 다중 가상 채널을 지원할 수 없다.

[이전] [목차] [다음]

i.MX 8M Plus 개발 환경 구축 - U-Boot 빌드

까마귀75 — Fri, 7 Apr 2023 13:38:22 +0900

[이전] [목차] [다음]

U-Boot 빌드

여기서는 U-Boot를 다운로드/빌드/로드하는 방법을 설명한다. IMXBSPPG 설명을 기반으로 독립 실행형 환경과 Yocto Project로 진행한다.

앞에서 이미 Yocto Project 설정을 했으므로, Yocto Project 설정 부분은 설명 없이 넘어간다.

독립 실행형 환경(standalone envirnoment)에서 U-Boot 빌드

작업 전 준비 사항

독립 실행형 환경에서 U-Boot를 빌드하려면, 먼저 호스트 시스템에 설치하여 컴파일하기 위한 개발용 SDK(툴, 툴 체인, 작은 rootfs 포함)를 생성해야 한다.

먼저 이미지를 생성 후, SDK를 생성하는 것을 권장한다. SDK부터 생성하려고 하면 에러가 발생할 수 있다(에러가 발생하는 이유를 찾지 못 했다).

예로, 아래과 같이 먼저 이미지를 생성하고,

$ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b bld-full
$ bitbake imx-image-full

아래와 같이 SDK를 생성한다.

$ bitbake imx-image-full -c populate_sdk

SDK가 에러 없이 생성이 되면, 빌드 디렉토리의 tmp/deploy/sdk에서 .sh 파일을 빌드하려는 호스트 시스템으로 복사하고, 해당 파일을 실행하면 SDK를 설치할 수 있다. 기본 설치 위치는 /opt이지만, 호스트 시스템 어디에나 설치할 수 있다.

호스트 시스템에서 U-Boot 빌드 단계

▶ i.MX 8 SoC용 U-Boot를 빌드하기 전에 아래 커맨드를 실행하여 호스트 환경을 설정한다.

ⓐ 5.15-kirkstone를 사용하는 경우

$ source /opt/fsl-imx-wayland/5.15-kirkstone/environment-setup-armv8a-poky-linux
$ export ARCH=arm64

ⓑ 6.1-langdale를 사용하는 경우

source /opt/fsl-imx-wayland/6.1-langdale/environment-setup-armv8a-poky-linux
export ARCH=arm64

▶ 다음 커맨드를 실행하여 저장소에서 U-Boot 소스를 다운로드한다(현재 저장소에서 기본 버전은 lf_v2022.04이다).

$ git clone https://github.com/nxp-imx/uboot-imx
또는
$ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2022.04

▶ 다운로드한 디렉토리로 이동하여, 다음 커맨드를 실행하여 U-Boot를 빌드한다.

$ cd uboot-imx
$ make distclean
$ make imx8mp_evk_defconfig
$ make

빌드시 아래와 같은 에러가 발생하면,

tools/mkeficapsule.c:21:10: fatal error: gnutls/gnutls.h: No such file or directory

다음 패키지를 설치하여 다시 make를 실행한다.

$ sudo apt-get install libgnutls28-dev

빌드가 완료되면 uboot-imx/ 디렉토리에 u-boot.bin이 생성된다.

imx-mkimage를 사용하여 imx-boot 이미지 빌드 단계

▶ 아래의 커맨드를 실행하여 저장소에서 imx-mkimage를 다운로드한다.

ⓐ 5.15-kirkstone를 사용하는 경우

$ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-5.15.32_2.0.0

ⓑ 6.1-langdale를 사용하는 경우

$ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-6.1.1_1.0.0

imx-mkimage 디렉토리가 생성되면서 파일들이 다운로드된다.

▶ 아래의 단계별로 필요한 파일들을 복사한다.

u-boot/tools/mkimage를 imx-mkimage/iMX8M/mkimage_uboot로 이름을 변경하여 복사한다.
u-boot/spl/u-boot-spl.bin을 imx-mkimage/iMX8M/로 복사한다.
u-boot/u-boot-nodtb.bin을 imx-mkimage/iMX8M/로 복사한다.
u-boot/arch/arm/dts/imx8mp-evk.dtb를 imx-mkimage/iMX8M/로 복사한다.
Arm Trusted Firmware(imx-atf) bl31.bin을 imx-mkimage/iMX8M/로 복사한다(Yocto Project의 /tmp/deploy/images/imx8mp-lpddr4-evk/imx-boot-tools/bl31-imx8mp.bin를 이름을 변경하여 복사한다).
firmware-imx 패키지의 signed_hdmi_imx8m.bin을 imxmkimage/iMX8M/로 복사한다(Yocto Project의 /tmp/deploy/images/imx8mp-lpddr4-evk/imx-boot-tools/signed_hdmi_imx8m.bin).
firmware-imx 패키지의 lpddr4_pmu_train_1d_dmem_202006.bin, lpddr4_pmu_train_1d_imem_202006.bin, lpddr4_pmu_train_2d_dmem_202006.bin, lpddr4_pmu_train_2d_imem_202006.bin을 imx-mkimage/iMX8M/로 복사한다(Yocto Project의 /tmp/deploy/images/imx8mp-lpddr4-evk/imx-boot-tools/).

▶ 다음 커맨드를 실행하여 imx-boot-image를 생성한다.

make SOC=iMX8MP flash_evk

imx-boot-image인 flash.bin이 생성된다.

Yocto Project에서 U-boot 빌드와 로드

<build-dir>/tmp/work/imx8mp_lpddr4_evk-poky-linux/u-boot-imx/2022.04-r0/git/에서 필요한 작업 후 아래 커맨드를 수행한다.

$ bitbake -f -c compile u-boot-imx
$ bitbake -f -c deploy u-boot-imx
$ bitbake -f -c install u-boot-imx
$ bitbake -f -c compile imx-boot
$ bitbake -f -c install imx-boot
$ bitbake -f -c deploy imx-boot

빌드 후 <build-dir>/tmp/deploy/images/imx8mp-lpddr4-evk에서 부트 바이너리 imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk를 찾을 수 있다.

[이전] [목차] [다음]