ほとんどの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デバイスのサポートを追加するのに苦労した理由の1つは、Linuxカーネルの排他的なコンポーネントによるものです。 ARMは本当に台無しです。特に、小型デバイスのSOCタイプのARMはさらにそうです。 Raspberry piなどのサポートハードウェアや、時間の経過とともにサポートされている他の同様のボードを使用しても問題ありません。 ARMデバイスツリーも非常に複雑で、x86タイプのブートロジックとは非常に異なります。デフォルトでは、それぞれは一意です。覚えておいてください。 「彼ら」はありません。利益を生み出し、費用を避ける努力には経済的利益がある。
これが、グローバルコミュニティの大規模プロジェクトが良い選択である理由の1つです。進行中のカーネル/ブート問題を解決する人がいて、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カードから「カーネルイメージ」、「デバイスツリーブロブ」、（必要な場合）「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で使用するマッピングとして使用する必要があります。
私はこれに対する修正を歓迎しますが、少し異なりますが、非常にカーネル指向の方向からこれらのものにアクセスしたときにおおよそのものを見つけました。
だから、2つの間に比較はありません。私は個人的に彼らがARM / SOC仕様を作るときに非常に深刻な設計ミスだと思います。これは、x86マザーボードとシステムについて概説されていますが、特にSOC / ARMデバイスに再導入された70年代/80年代/90年代スタイルの混乱した混乱を作成したためです。 。非常に複雑です。
しかし、ARMサーバーのようなものはこのようには機能しません。たとえば、ブートのためにカーネルに標準のPCIバスを提供しますが、デバイスツリーの種類やカスタムブート設定も必要なのかどうかはわかりません。私はARMサーバーに切り替える計画を持っていた人を知っています。しかし、私が知っている限り、彼はすべてのパッケージとツールチェーンを再構築するのが難しいので、切り替えませんでした。だから私が最後に確認したとき、彼はまだx86_64にいます。
SOC ARMデバイス、MIPS、PowerPC、RISC-Vなどのデバイスツリーや起動設定を完全に理解するための重要な専門知識がないため、これを回答として公開しません。多くの点で似ています。
考えられる一つの考えは、SOCが「IP」と呼ぶものの集合であると考えることです。これは通常、独自の知的財産、つまりマリグラフィ、ネットワーキング、ブルートゥースなどの特定のタスクを実行できるデザインです。彼らはSOCチップを設計するためにそれを使用します。そのため、システムオンチップと呼ばれます。チップ自体には多くのコンポーネントがあり、コストを削減し、設計プロセスをスピードアップするのに役立ちます。
Linuxでは、Bluetoothの例として、デバイスはデフォルトで常にUSBバス（標準）またはPCIバス（あまり一般的ではありません）の2つの場所のいずれかにあり、すべてのBluetoothデバイスはBluetooth USBプログラムを介してLinux上でUSB用のドライバを実行します。一方、Raspberry pi バージョン 3 と 4 には、私が知っている限り、Raspberry pi でのみ使用される非常にカスタマイズされたタイプがあり、データをインポートすることも非常に難しく、場所を決定することは困難です.ドライバーは排他的です（肯定的ではありませんが、そうであると仮定してそれを確認する人は誰もいません）。
問題をより複雑にすることは、一部のSOCにはSOCとIPだけでなく、一部のエントリが実行されるPCIバスもあることです。
さまざまなSOC ARMサポートLinuxプロジェクトに参加した記憶によると、基本的にはボード固有のケースでした。ちなみに、これが完全に独占的なプライベートハードウェアとドライバを持っている携帯電話をアップグレードするのが難しい理由でもあります。これは、ほとんどの携帯電話用Linuxプロジェクトが一般的にGoogleのPixelでサポートされている携帯電話の少数のリストのみを持つ傾向がある理由です。例えば。