최신 Linux 커널로 x86 장치를 업그레이드하는 것보다 ARM 장치를 업그레이드하는 것이 더 어려운 이유는 무엇입니까?

최신 Linux 커널로 x86 장치를 업그레이드하는 것보다 ARM 장치를 업그레이드하는 것이 더 어려운 이유는 무엇입니까?

대부분의 ARM 기반 소비자 장치는 LTS 커널 릴리스에서 동결되고 업데이트되지 않습니다(Android, Chrome OS, IoT 장치 등). 그러나 x86 장치가 있는 경우 일반적으로 커널만 업그레이드하면 됩니다!

두 장치의 커널 모듈/드라이버가 업스트림이라고 가정합니다.

장치 트리가 동일하다고 가정하면 다른 컴퓨터처럼 업그레이드하면 안 되나요?

답변1

[업데이트] phuctv 참고사항:

ARM에는 SBSA/SBBR이 있으며 이러한 기능을 갖춘 시스템은 x86과 정확히 동일한 UEFI를 가지며 UEFI 호환 ISO 이미지 또는 드라이브를 부팅할 수 있습니다. 더 이상 장치 트리가 필요 없으며 SBSA용으로 구축된 ISO는 UEFI가 있는 모든 ARM 보드에서 부팅할 수 있습니다. Raspberry Pi 4의 SBBR도 지원됩니다.

이를 염두에 두고 이것이 실제 돈이 있는 ARM 서버에 대부분 영향을 미칠 것이라는 것이 합리적이며 phuctv가 지적한 것처럼 Raspberry pi 4는 이를 지원합니다. 하지만 이 작업을 수행할 수 있는 다른 SOC 유형 보드가 많이 있을지 의심됩니다. 그러나 전반적으로 질문은 ARM 서버보다는 일반적으로 소형 ARM SOC 유형 장치와 더 관련이 있기 때문에 지금까지 아래 답변을 크게 변경하지는 않습니다.

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

역사적으로 ARM 기반 제품은 특정 애플리케이션과 전력 구성에 맞게 맞춤화되는 경우가 많았습니다. ARM 기반 하드웨어 플랫폼 간의 차이점은 장애물이 되어 각 제품에 맞게 운영 체제를 조정해야 했습니다.

SBSA는 이 표준 플랫폼용으로 구축된 운영 체제가 사양을 준수하는 모든 하드웨어 제품을 수정하지 않고도 올바르게 실행할 수 있도록 최소한의 표준화된 기능 집합을 지정하여 ARM 생태계를 강화하는 것을 목표로 합니다.

이를 통해 서버가 아닌 SOC인 대부분의 ARM 장치인 SBSA가 없는 시스템에 다음을 적용할 수 있습니다.

사전 수정된 답변:

ARM/MIPS 유형 장치를 부팅하는 것은 x86 유형 장치를 부팅하는 것과 매우 다릅니다. 훨씬 더 복잡합니다. 또한 대부분의 SOC 유형 장치는 판매 후 제조업체에 이익이 전혀 발생하지 않지만 독점 드라이버 등을 유지하는 데 비용이 들기 때문에 경제적 이유가 없습니다. 삼성이나 애플 같은 고급 제품은 돈이 더 많이 들기 때문에 업데이트하는 데 시간이 더 오래 걸리는 경향이 있습니다. 최신 커널로 마이그레이션하려면 드라이버 등을 위한 프로그래밍 시간이 매우 많이 필요할 수 있으며 종종 이점이 없으므로 수행할 수 없습니다. –

업스트림에 대한 귀하의 가정도 틀렸다고 생각합니다. 내 기억이 맞다면 BSD가 ARM 장치에 대한 지원을 추가하는 데 어려움을 겪은 이유 중 하나는 Linux 커널의 독점 구성 요소 때문이었습니다. ARM은 정말 엉망입니다. 특히 소형 장치 SOC 유형의 ARM은 더욱 그렇습니다. Raspberry pi와 같은 지원 하드웨어나 시간이 지남에 따라 지원되어온 기타 유사한 보드를 사용하면 괜찮을 것입니다. ARM 장치 트리도 매우 복잡하고 x86 유형 부팅 논리와 매우 다릅니다. 기본적으로 각각은 고유한 것입니다. 기억하세요. "그들"은 없습니다. 이익을 창출하고 비용을 피하려는 노력에는 경제적 이익이 있습니다.

이것이 글로벌 커뮤니티의 대규모 프로젝트가 좋은 선택인 이유 중 하나입니다. 진행 중인 커널/부팅 문제를 해결하는 사람들이 있고 Raspberry Pi 2, 3, 3b, 4, Zero 등과 같은 대규모 사용자 기반이 있습니다. ., 그래서 각 세대의 하드웨어에 대한 지원을 추가하는 것을 다루는 커뮤니티가 있지만 다른 SOC에서는 공급업체가 OS/커널을 만들 수 있으며 누군가가 할 수 없는 한 이것이 실행할 수 있는 유일한 커널일 가능성이 높습니다. 핵심 콘텐츠는 지원을 얻기 위해 역설계되지만 이는 많은 작업이 필요하기 때문에 인기가 매우 높은 경우에만 발생합니다.

이 내용에 대해서는 제가 사용할 만큼 충분히 알고 있지만, 구체적인 내용이나 복잡한 내용은 모르기 때문에 오해하고 싶지 않습니다. 예를 들어, Linux는 Raspberry pi와 같은 ARM SOC 보드를 최초로 지원했기 때문에 공급업체로부터 독점 펌웨어를 받았기 때문에 Linux에서 Raspberry pi가 지원된다고 생각합니다. 이로 인해 FreeBSD나 OpenBSD가 이러한 작업을 제대로 실행하는 것은커녕 시작조차 하기 어렵습니다. 이것을 테스트했을 때 우리는 NetBSD를 Raspberry Pi 4에서 부팅할 수도 없었습니다. 그리고 그것은 "무엇이든 작동"하는 운영 체제입니다. 다른 BSD의 성능은 끔찍합니다. Linux 커널에 중요한 독점 비트가 없기 때문인 것이 거의 확실합니다. 이 테스트는 약 8개월 전에 한 것으로 생각되므로 변경되었을 수 있지만 이는 1월/2월에 있었던 일이고 이 장치는 수년 동안 시장에 출시되었습니다.

이 기사https://yuhei1-horibe.medium.com/building-and-booting-complete-customized-os-on-raspberry-pi-f743899c79dARM SOC(이 경우 pi)에서 Linux를 부팅하는 것과 관련된 세부 정보를 살펴보세요.

빌드하기 전에 특정 대상 하드웨어에 맞게 구성해야 합니다. 제 경우에는 "Raspberry pi 3B"용으로 특별히 구성했습니다. 이렇게 하면 Raspberry Pi의 기본 구성을 찾을 수 있습니다.

하드웨어의 기본 구성을 교체해야 합니다. 또는 대화형 "menuconfig"를 사용하여 "기본 시작 명령", "시간 초과" 등을 사용자 정의할 수 있지만 필수는 아닙니다.

기본적으로 SD 카드에서 "커널 이미지", "장치 트리 blob" 및 (필요한 경우) "initrd"를 읽어 DRAM에 넣는 것입니다. 또한 중요한 것은 "kernel bootarg"입니다. 외부 저장소(root=/dev/sda1)에서 루트 파일 시스템을 마운트하기 때문에 이를 사용자 정의하는 것이 중요합니다.

...

커널을 구성하고 u-boot처럼 빌드합니다. 커널의 경우 구성 파일은 "arch/arm64/configs" 폴더에 있습니다.

이번에는 프로필이 3개만 있습니다. Raspberry pi 3인 경우 bcmrpi3_defconfig를 선택합니다.

주요 차이점에 주목하세요. 단일 커널(예: AntiX, Debian)은 거의 모든 x86/x86_64 보드에서 부팅할 수 있지만 브랜드뿐만 아니라 Raspberry Pi와 같은 특정 버전에 대해 각 SOC 보드에 대한 커널을 만들어야 합니다. B3, 4 등 그래서 당신은 특정 장치와 부트로더를 위한 커널을 구축하고 있습니다. 제 생각에는 대략 정확하고 이러한 것들에 대한 제가 이해한 것과 일치합니다.

다시 한 번 말씀드리지만, 가장 큰 차이점은 x86 하드웨어에서 Linux 커널을 부팅한 다음 하드웨어를 검색하기 시작하고 grub 또는 lilo를 통해 BIOS/uefi에서 기본 부팅 시나리오를 가져오는 것입니다. .

SOC ARM은 하드웨어, 디바이스 트리 등이 무엇인지 미리 알고 이를 SOC와 함께 사용할 매핑으로 사용해야 합니다.

나는 이것에 대한 수정을 환영하지만 약간 다르지만 매우 커널 지향적인 방향에서 이러한 것들에 접근할 때 대략적으로 발견한 것입니다.

그래서 둘 사이에는 비교가 없습니다. 나는 개인적으로 그들이 ARM/SOC 사양을 만들 때 매우 심각한 설계 실수라고 생각합니다. x86 마더보드 및 시스템에 대해 대체로 정리되었지만 특별히 SOC/ARM 장치에 다시 도입된 70년대/80년대/90년대 스타일의 혼란스러운 혼란을 만들었기 때문입니다. . 매우 복잡한.

그러나 ARM 서버와 같은 것은 이와 같이 작동하지 않습니다. 예를 들어 부팅을 위해 커널에 표준 PCI 버스를 제공하지만 일종의 장치 트리나 사용자 정의 부팅 설정도 필요한지는 모르겠습니다. 저는 ARM 서버로 전환할 계획을 갖고 있던 사람을 알고 있습니다. 하지만 제가 아는 한 그는 모든 패키지와 툴체인을 다시 빌드하는 것이 너무 어렵기 때문에 전환하지 않았습니다. 그래서 제가 마지막으로 확인했을 때 그는 아직 x86_64에 있습니다.

SOC ARM 장치, MIPS, PowerPC 또는 RISC-V 등의 장치 트리 및 부팅 설정을 완전히 이해할 수 있는 핵심 전문 지식이 없기 때문에 이것을 답변으로 게시하지 않을 것입니다. 여러 면에서 비슷해요.

한 가지 가능한 생각은 SOC가 "IP"라고 부르는 것의 집합이라고 생각하는 것입니다. 이는 일반적으로 독점 지적 재산, 즉 말리 그래픽, 네트워킹, 블루투스 등과 같은 특정 작업을 수행할 수 있는 디자인입니다. 그들은 SOC 칩을 설계할 때 이를 사용합니다. 그래서 시스템 온 칩(System on a Chip)이라고 합니다. 칩 자체에 많은 구성 요소가 있어 비용을 절감하고 설계 프로세스 속도를 높이는 데 도움이 됩니다.

Linux에서 Bluetooth를 예로 들면, 장치는 기본적으로 항상 USB 버스(표준) 또는 PCI 버스(덜 일반적임) 두 위치 중 하나에 있으며 모든 Bluetooth 장치는 Bluetooth USB 프로그램을 통해 Linux에서 USB용 드라이버를 실행합니다. 반면에 Raspberry pi 버전 3과 4에는 내가 아는 한 Raspberry pi에서만 사용되는 매우 사용자 정의 유형이 있으며 심지어 데이터를 가져오는 것도 매우 어렵고 위치를 결정하기가 어렵습니다. 드라이버는 독점입니다(긍정적이지는 않지만 그렇다고 가정하고 이를 확인할 사람이 아무도 없습니다).

문제를 더욱 복잡하게 만드는 것은 일부 SOC에는 SOC 및 IP뿐만 아니라 일부 항목이 실행되는 PCI 버스도 있다는 것입니다.

다양한 SOC ARM 지원 Linux 프로젝트에 참여했던 기억에 따르면 기본적으로 보드별 사례였습니다. 덧붙이자면, 이것이 완전히 독점적인 비공개 하드웨어와 드라이버를 갖고 있는 휴대폰을 업그레이드하는 것이 어려운 이유이기도 합니다. 이것이 바로 대부분의 휴대폰용 Linux 프로젝트가 일반적으로 Google의 Pixel에서 지원되는 휴대폰의 소수 목록만 갖는 경향이 있는 이유입니다. 예를 들어.

관련 정보