5번 강의 '추가 업데이트 자료 - 패치 및 추가 자료'에 패치 코드와 빌드 스크립트(uboot_ patch.zip )를 올렸습니다. 5번 강의의 '수업 노트 작성'에 패치 코드와 수업의 전체 위치를 알 수 있게 아래와 같은 내용을 업데이트했습니다. 또한 패치 파일이 필요한 각각 실습 수업의 수업 자료에 패치 코드도 업로드했습니다. --- 첨부된 파일(uboot_ patch.zip ) 내려 받고, 압축을 해제하면 다음과 같은 파일을 확인할 수 있습니다. 파일의 목록된 사용된 수업의 이름은 아래와 같습니다. - build_uboot_ arm64.sh : U-Boot 빌드 스크립트 (rpi_4_defconfig) QEMU 및 소스 브링업 전체 실습에서 활용 - qemu_build_uboot_ arm64.sh : U-Boot 빌드 스크립트 (qemu_arm64_defconfig) QEMU 및 소스 브링업 전체 실습에서 활용 - debug_qemu_build_uboot_ arm64.sh : QEMU 디버깅용 이미지 빌드 스크립트 릴리즈 버전 및 디버그 버전 별로 빌드 아키텍처 구성하기 - preprocess.patch: 전처리 추출 패치 U-Boot 실습 (Source Bring-up) - Part1 (세션) | 전처리 파일을 추출하는 방법과 전처리 코드 분석 (rpi_4_defconfig) - logging_uart.patch: 아래 강의에서 사용된 패치 U-Boot 실습 (Source Bring-up) - Part2 (세션) | 리눅스 QEMU로 U-Boot 실행하기 - qemu_TARGET_BRINGUP_DEBUG.patch: 아래 강의에서 사용된 패치 U-Boot 실습 (Source Bring-up) - Part2 (세션) | 새로운 Kconfig 추가하기 (CONFIG_TARGET_BRINGUP_DEBUG) - 0001-u-boot-adding-TARGET_BRINGUP_KERNEL_ADDRESS-for-sett.patch: 환경 변수 (Environment Variables)와 DTB 부트 아규먼트 처리(세션) | 환경 변수 변경 실습 2: CONFIG_* 추가 - (QEMU 디버깅) --- 감사합니다.
먼저 제 강의를 들어주셔서 감사합니다. 리눅스 시스템에 대한 내용을 파악하시려면 아래 순서로 들으시면 됩니다. 먼저 '리눅스 소개와 리눅스 커널 Overview [저자직강 1부-1]' 강의를 들으시면 좋습니다. 리눅스 시스템에 대한 전반적인 내용을 다루거든요. 그 다음에 '리눅스 커널의 구조와 원리: 디버깅 - Basic [저자 직강 1부-2]' 과정을 들으시면 됩니다. 이 강의는 실무에서 바로 쓰이는 리눅스와 관련된 내용을 담고 있습니다. 조만간 한 두 달 이내에 '리눅스 기반의 부트로더'와 '리눅스 디바이스 드라이버 브링업 강의'가 출시될 예정이니, 나중에 이 강의도 참고하셨으면 좋겠습니다.
Armv8-A 기반의 프로젝트를 진행하시면, 먼저 Armv8-A 관련 강의를 들으시면 됩니다. Armv7-A는 레퍼런스로 참고하시면 되는데요. 그 이유는 다음과 같습니다: Armv8-A에서 확인되는 많은 용어는 Armv7-A에서 사용된 용어를 이어서 사용하는 경우가 많습니다. Armv8-A 기반의 Cortex 프로세스에서 시스템의 설정에 따라 유저 스페이스를 32비트로 사용하는 경우도 있습니다. 이 점 참고하셨으면 좋겠습니다. 감사합니다.
(늦게 답변을 드려서 죄송합니다.) 제가 진행한 이번 강의는 너무 Arm 아키텍처 관점으로만 SPn와 SP를 설명드린 것 같습니다. 일반적으로 EL0이나 EL1, EL2 그리고 EL3에서는 소프트웨어 관점으로 바라보는 스택은 SP 레지스터로만 관리됩니다. 함수를 C 언어로 프로그램한 다음에 해당 코드를 어셈블리 명령어로 분석하면 SP 레지스터만 보일 뿐입니다. 예를 들어, 아래 코드를 보겠습니다. NUX:FFFFFFC010B05F90|__smccc_workaround.:hint #0x10 ; #16 NUX:FFFFFFC010B05F94| sub sp,sp,#0x20 ; sp,sp,#32 'sub sp,sp,#0x20' 명령어는 실행되는 위 코드가 실행되는 익셉션 레벨에 따라 아래 레지스터가 함께 업데이트 됩니다 - EL0: sp, sp_el0 - EL1: sp, sp_el1 - EL2: sp, sp_el2 - EL3: sp, sp_el3 감사합니다.
늦게 답신드려서 죄송합니다. 펩리스 업체에서 개발하는 주요 정보는 외부에 공유되어 있지 않아 구체적으로 답변을 드리기는 어렵습니다. 일반화하면 - 현업 Video IP/DSP는 대부분 아래 흐름으로 처리됩니다. Linux driver probe: 리눅스 플렛폼 디바이스 구조 파악 + 디바이스 트리 firmware binary loading: request_firmware() 등등의 커널 API 사용 방법 reserved memory mapping: 디바이스 트리로 메모리 매핑을 설명 mailbox/interrupt communication: request_irq() 함수를 사용해서 인터럽트 등록 DSP start 위와 같은 시나리오로 코드를 분석하시고, 간단한 mock firmware loading project를 진행하시면 좋겠습니다. 조금 더 구체적인 답변을 드리지 못하는 점 양해 부탁드립니다.
