내 노트북과 데스크톱에 Ubuntu Desktop을 설치하려면 Ubuntu 웹사이트에서 동일한 이미지를 다운로드하면 됩니다. 이는 제가 들어본 거의 모든 Linux 배포판에서 작동합니다.
저는 현재 다양한 Raspberry Pi 교체품을 쇼핑하고 있는데 각각 고유한 운영 체제가 필요하다는 것을 알게 되었습니다. 예를 들어,앰비안지원하는 모든 보드에 대한 다운로드가 있습니다. 마찬가지로 Raspbian이 OrangePi에서 즉시 작동하지 않는 이유는 무엇입니까? armv6/armv7/armv8에 대해 서로 다른 이미지가 필요할 수 있다는 점은 이해합니다. 그런데 각 SBC에 자체 이미지가 필요한 이유는 무엇입니까?
답변1
이 질문에 대한 대답은 매우 미묘합니다. 그러나 근본적인 이유는 (x86/x86_64) PC가 매우 다양해 보이지만 그렇지 않기 때문입니다. SBC(일반적으로 ARM 기반)는 더욱 다양하며 심지어 ARM CPU라도 SBC 간에 큰 차이가 있을 수 있습니다.
개인용 컴퓨터 역사
PC의 다양성이 부족한 이유는 다소 의견에 근거한 것일 수 있지만 Microsoft DOS 및 Microsoft Windows와 관련이 있을 것이라고 추측해 봅니다. 역사적으로 그들은 엄격한 요구 사항을 가지고 있었습니다. 나믿다초기에는 이것이 가능했기 때문에 "IBM 호환 PC"승리했습니다. Microsoft는 그 요구 사항을 충족하기 위해 소프트웨어를 만들었습니다. 그 후 Microsoft는 지배적이 되어 원하는 것은 무엇이든 요구할 수 있었고 하드웨어 공급업체는 이를 따라야 했습니다."
마찬가지로 Intel은 AMD와 같은 다른 제조업체가 경쟁하기 위해 자사의 CPU가 Intel의 CPU와 호환되는지 확인해야 할 만큼 지배적인 위치를 차지하고 있습니다. 비록 역사상 흥미로운 점은우리가 지금 x86_64라고 부르는 것은 실제로 AMD64라고도 알려진 AMD의 발명품입니다..
단일 보드 컴퓨터(ARM)
대부분의 SBC는 ARM 기반이며 동일한 역사가 없습니다. ARM은 실제로 CPU를 전혀 만들지 않으며 단지 제조업체에 설계 라이센스를 부여할 뿐입니다. 이를 통해 다양한 제조업체가 이러한 디자인을 맞춤화할 수 있으며 이를 표준화해야 하는 상업적 압력이 충분하지 않습니다.
ARM SBC 다양성 실무 문제
명령어 세트
PC에는 매우 안정적인 핵심 명령어 세트가 있습니다. 예, 다양한 Intel/AMD CPU에는 일부 고급 기능에 대한 몇 가지 추가 지침 세트가 있지만 대부분의 경우 운영 체제를 실행하는 데 그다지 중요하지 않습니다. 실행할 수 있는 응용 프로그램에 영향을 줄 수 있습니다.
그러나 ARM SBC의 경우 명령어 세트에 더 큰 차이가 있습니다. 예를 들어, 최초의 Raspberry PI가 만들어졌을 때 ARM CPU를 사용했고하드웨어 부동 소수점당시 다른 주요 Linux 배포판(예: Debian)은 이 기능을 지원하도록 컴파일되지 않았습니다. 기술적으로는 작동할 수 있지만 그렇게 될 것입니다.많은그것 없이는 더 느려질 것입니다.
이제 핵심 CPU 기능과 명령어 세트가 커널뿐만 아니라 설치하는 모든 소프트웨어 패키지에서도 사용된다는 점을 이해하는 것이 중요합니다. 하드웨어 부동 소수점 지원을 원하지만 운영 체제 배포판이 이에 대해 컴파일하지 않는 경우 시스템의 모든 패키지를 다시 컴파일해야 합니다.
커널 구성
CPU의 다른 기능으로 인해 몇 가지 까다로운 문제가 발생합니다. 이는 많은 ARM SBC가 Linux 커널을 수정해야 함을 의미합니다. 이제 단지 커널만을 위해 완전히 새로운 배포판을 출시하는 것은 좀 무리인 것 같습니다. 하지만 한 가지는 사실입니다.
Raspbian이 OrangePi에서 즉시 작동하지 않는 이유는 무엇입니까?
시작 문제(아래)를 극복할 수 있더라도 여전히 중요한 것이 누락되어 있음을 발견할 수 있습니다.커널 적용 범위. 결과적으로 단순히 기능이 누락되거나 커널이 부팅되지 않을 수도 있습니다.
시작하다
일반적으로 출시는 완전히 새로운 운영 체제를 출시하는 이유가 아닙니다. 하지만 조심해서 다뤄야 합니다.
PC에서 하드웨어 초기화의 대부분은 표준화되거나 BIOS에 의해 처리됩니다. BIOS는 제조업체에서 제공한 소프트웨어를 저장하고 운영 체제보다 먼저 실행됩니다. 그런 다음 부트로더를 찾고 실행하는 일을 담당합니다.
ARM SBC에는 BIOS가 없습니다. 동등한 소프트웨어가 운영 체제와 함께 제공됩니다. 이제 기술적으로는 오픈 소스 운영 체제가 이 펌웨어를 서로 공유하는 것을 막을 수 없습니다(참조Raspberry Ri용 bootcode.bin 라이센스). 하지만 이는 모든 운영 체제가 서로 다른 모든 SBC에 대해 해당 펌웨어의 복사본을 가지고 있어야 함을 의미합니다. 그리고 다양한 SBC가 있습니다.
저는 다른 SBC가 기존 운영 체제의 자체 ISO를 공개함으로써 이 문제를 해결했다고 생각합니다. 비글보드가 바로 그런 일을 합니다.
답변2
이것은 훌륭한 질문이고 불행히도 답을 아는 사람은 거의 없지만 이 지식은 여전히 매우 중요합니다. 다만, 간결한 답변이 불가능하오니 솔직하게 말씀해 주시기 바랍니다.
편집하다: 이 기사는 한 가지 사항을 요약합니다."ARM은 마침내 서버실을 목표로 플랫폼을 정의했습니다." - Ars Technica
기본 지식:
운영 체제를 부팅하려면 모든 컴퓨터가 다음 필수 단계를 수행해야 합니다(약어 참고).
- 시간하드웨어나초기화에스시퀀스(매우 알몸으로 로드 중"두번째ASIC운전사" 을 위한프론트 사이드 버스완료)
- 에프첫 번째에스꼬리표두번째ootloader(BIOS, UEFI, U-BOOT, "프로그램", "부트로더" 등)
- 두 번째 단계 부트 로더(GRUB, LILO, SYSLINUX, BOOTMGR 등)
BDriver는 주로 일부 마더보드 구성 요소와 버스를 초기화하는 데 사용됩니다.
모든 것이 다른 곳:
- AMD64/EM64T(Intel)/x64 플랫폼에서,하드웨어 초기화순서는 매우 표준화된 절차입니다. 이를 위해서는 컴퓨터 제조업체(OEM) BDrivers를 표준화된 FSB에 내장하여 CPU를 시작할 수 있습니다.
이는 x64 하드웨어가 매우 다양하지만 FSB는 동일하다는 것을 의미합니다.하나의 ISO가 모든 요구 사항을 충족합니다.. 그렇기 때문에 OEM이 2009년경에 소프트웨어 지원을 중단하더라도 2021년(및 그 이후)부터 Windows XP 2005 PC/노트북을 최신 Windows 10 또는 Linux로 업그레이드할 수 있습니다.
- 대조적으로, ARM 플랫폼은 그러한 표준화 및OEM은 필수가 아닙니다.BDriver는 FSB에 내장되어 있으며 FSB는 내장되어 있지도 않습니다. 이는 BDrivers를 포함해야 함을 의미합니다.그리고자신의 FSB를 자신의 이미지에 통합하세요.
하드웨어가 매우 다양하기 때문에하지만FSB도 다양합니다.모든 ISO에 적합한 사람은 없습니다.. 이는 GPU가 CPU를 부팅하는 Raspberry 3(!)과 같이 이상하고 무의미한 FSB 시퀀스가 나타나는 이유를 설명합니다.
편집: ARM 플랫폼(커널, 모든 시스템 라이브러리, 최종 사용자 소프트웨어)에서 작동하기 위해 이미지의 모든 항목을 다시 컴파일하는 것에 대해 말하는 것이 아닙니다.
문제, 단편화:
ARM 플랫폼에서의 이러한 차이점은 다음을 의미합니다.BDrivers의 가용성은 전적으로 OEM의 선의에 달려 있습니다.이렇게 하면 다운로드할 수 있습니다.
불행하게도 지난 10년 동안 우리는 주류 ARM 장치(예: Android/Apple 장치)가 어떻게 작동하는지 살펴보았습니다.OEM만이 BDrivers를 사용하는 유일한 운영 체제 버전이므로 OEM만 업그레이드할 수 있습니다..
이러한 BDriver가 없으면 누구도 쉽게 사용자 정의 ROM이나 이미지를 만들 수 없습니다. 따라서 Android 장치의 사용자 정의 ROM은 강제 리버스 엔지니어링으로 인해 시간이 오래 걸리고 만들기 어려운 이유이며 Apple 장치용 사용자 정의 iOS 또는 Android 이미지를 만드는 방법을 아는 사람은 거의 없습니다.
UEFI, U-Boot 등은 ARM에서도 저장되지 않습니다.
모든 것이 x64 플랫폼에서와 같이 작동하도록 ARM 플랫폼에 표준화된 FSB만 있으면 된다고 가정하기 쉽습니다.
- 어느 것이100% 틀린 것으로 판명됐어요...Microsoft에서 제작한 Surface(RT, 2012) 및 Surface 2(2013),일부 UEFI는 해당 장치에 존재합니다.. 이 태블릿도 참고하세요.다른 ARM 장치와 마찬가지로 자체적인 독립적인 이미지가 있습니다., Microsoft가 몇 년 전 지원을 중단한 이후 Windows 10으로의 공식적인 업그레이드 없이 Windows 8.1에서 공식적으로 중단되었습니다.
8년이 지난 후에도 ARM 장치와 동일한 이유로 이러한 Surface에 대한 사용자 지정/커뮤니티 개발 Windows 10 이미지를 제공하는 것은 거의 불가능합니다.이는 Microsoft가 앞서 언급한 BDrivers 출시를 원하지 않기 때문입니다..
현재(2021년)까지 거의 10년 동안 다른 모든 Microsoft Surface 제품은 x64 플랫폼에서 출시되었습니다. x64 플랫폼은 22개의 x64 장치에 4개의 ARM 장치입니다.
arm64
최근 예외는 UEFI가 있음에도 불구하고 1.5년이 지난 후에도 여전히 표준 ISO를 부팅할 수 없는 Surface Pro X(2019년 10월)입니다 .Surface Pro X의 Linux 문제 - Github
이는 확실히 UEFI가 있음을 의미합니다.보장하지 않는다ARM 플랫폼에서 표준 이미지를 부팅할 수 있습니다.
ARM의 UEFI와 마찬가지로 U-Boot의 상황도 동일합니다.BDrivers 없음, 이미지 없음. 표준화된 FSB에 대한 희망도 있습니다.
거의 모든 Android 기기에서는 일반적으로 "부트로더"(FSB)라고 알려진 것이 OEM에 의해 잠겨 있기 때문에 상황이 더욱 악화됩니다. iOS 기기는 비공식적인 수단은 물론이고 공식적인 수단을 통해서도 잠금을 해제할 수 있는 기회조차 제공하지 않습니다.
ARM과 Google은 이 상황에 대해 어떻게 생각합니까?
- ARM조차도 ARM 플랫폼이 심각한 조각화 문제를 야기한다는 점을 인정합니다. 그들은 서버의 상황을 해결하려고 시도했습니다.SBSA2014년 이후:서버 인프라 시스템 아키텍처 - Wikipedia
그러나 불행하게도 SBSA 플랫폼이 탄생한 이후 몇몇 서버를 제외하고 이러한 유형의 SBSA 플랫폼에 대한 뉴스를 많이 본 적이 없으며 이는 SBSA가 단편화를 방지하는 데 실패했음을 보여줍니다.
더 나쁜 것은 계획된 노후화에 대한 마진이 너무 높고 너무 오랫동안 이런 식으로 유지되어 왔기 때문에 주류 플랫폼(휴대폰, 태블릿, PC 등)에서 SBSA와 같은 솔루션을 볼 가능성이 거의 없기 때문에 OEM이 이를 복원할지 여부 특히 Android/iOS 기기에서는 솔루션이 거의 불가능합니다.
- Google은 OEM에게 표준화된 FSB 시퀀스를 갖도록 강요할 수 없기
Project Treble
때문에 ARM 플랫폼으로 인해 발생하는 조각화 문제를 해결하려고 노력하고 있습니다 .Project Mainline
목표는 계획된 지원 중단으로 인해 특정 버전에 멈춰 있는 OEM ROM과 별개로 Android 시스템 업데이트를 제공하는 것입니다. 그러나 이는 아무것도 변경하지 않으며 맞춤형 ROM 개발자를 더욱 어렵게 만듭니다.
실제로 Google은 Android 인증 장치 프로그램을 통과할 때 OEM이 표준화된 FSB 시퀀스를 갖도록 강제할 수 있습니다.
하지만 AOSP는 오픈소스이므로 Google이 규정을 시행할 경우 OEM은 각자의 길을 갈 수도 있습니다. 이러한 상황은 이미 Huawei, Honor 휴대폰 및 "HarmonyOS"가 탑재된 기타 휴대폰에서 발생했습니다.“안드로이드 대탈출: 더 많은 휴대폰 제조사가 화웨이의 HarmonyOS로 전환할 수도 있다” - Techradar.
전체적으로 ARM 플랫폼 조각화를 우회하는 데 있어 어느 시도도 큰 진전을 이루지 못했습니다.
사실 ARM은 설계상으로 조각화되어 있습니다.
더 많은 조각화를 가져오는 큰 요인 중 하나는 "아키텍처"에서 "롤링 릴리스" 개발 스타일을 사용하는 ARM의 나쁜 습관입니다.
이로 인해 해결 방법 없이 잔인하고 교활한 기능 제거가 발생하는 경우가 많습니다.
- ARM 아키텍처 릴리스 치트 시트, 주요 변경 사항 - starfighter.acornarcade.com
- ARMv8 AArch32 모드는 armv4, armv5 또는 armv6과 역호환됩니까? , 스택 오버플로
- ARMv4/5/6 코드의 어떤 부분이 ARMv7에서 실행되지 않습니까? , 스택 오버플로
그곳에서는 작업이 진행 중입니다.
x64는 초기 64비트 CPU(AMD의 Athlon 64)부터 최신 CPU까지 호환성을 유지하지만 ARM은 32비트에서 수행한 작업을 수행하지 못할 수 있습니다.
- 32비트 ARM에서도 차이가 있습니다
armel
.armhf
- 자주
- 기업은 이제 ARM의 CXC 프로그램을 통해 명령어 세트를 조정할 수도 있습니다.
기억하고 고려해야 할 몇 가지 사항:
- ARMv1부터 ARMv7, A32 및 AArch32는 모두 32비트 ARM입니다. 즉, 64비트 ARM에서도 동일한 수준의 손상을 합리적으로 예상할 수 있습니다.
- x64에서는 갑자기 사라지는 기능이 거의 없습니다. 즉, 2021 CPU는 여전히 전체 32비트, 심지어 16비트 호환성(!)을 유지합니다. (드물게) 기능 제거가 발생하는 경우(3DNow! 등), 일반적으로 이를 우회할 수 있는 해결 방법이 있습니다.
- ARM은 x64에서 25년은 커녕 10년 동안의 하위 호환성과 안정성도 가질 수 없습니다.
- 우리는 여전히 완벽하게 작동하는 2005 x64 CPU를 보유하고 있으며 오늘날의 웹 브라우징에 여전히 충분히 강력합니다.
이러한 이전 버전과의 호환성은 조각화를 방지합니다.
폴리스티렌: 내 글이 정말 무거워요. 누구든지 더 잘 이해할 수 있도록 제안할 수 있습니다.