最初からオペレーティングシステム。 レベル1（古い半分）

次のパートの時が来ました。 これは、翻訳ラボ番号1の後半です。 この問題では、周辺機器ドライバー（タイマー、GPIO、UART）を記述し、XMODEMプロトコルと1つのユーティリティを実装します。 これらすべてを使用して、カーネルのコマンドシェルと、microSDカードを前後に動かさないようにするブートローダーを作成します。

下半分 。
読書はゼロラボで始まります 。

フェーズ3：貝殻ではない

今回は、統合された周辺機器用のドライバーをいくつか作成します。 組み込みタイマー、GPIO、およびUARTに興味があります。 それらは組み込みのコマンドラインを書くのに十分であり、少し後にブートローダーを作成するのに便利になります（これにより、さらに作業がいくらか簡単になります）。

ドライバーとは何ですか？

ドライバーまたはデバイスドライバーという用語は、特定のハードウェアデバイスと直接対話し、それを管理するソフトウェアなどです。 ドライバーは、制御するデバイスに高レベルのインターフェイスを提供します。 オペレーティングシステムは、デバイスドライバーと対話して、それらの上にさらに高度な抽象化を構築します（もちろん、便宜上）。 たとえば、Linuxカーネルは、ドライバーと対話するオーディオ用のAPIであるALSA（Advanced Linux Sound Architecture）を提供し、ドライバーはサウンドカードと直接通信します。

サブフェーズA：はじめに

割り当ての残りの部分では、 osカブの内部で作業します。これは、この部分だけでなく、コースの残りの部分でも使用されます。 最終的にオペレーティングシステムになるのは、このリポジトリです。

このコースを参照して、ラボなどすべてに次のディレクトリ構造をお勧めします。

 cs140e ├── 0-blinky │ ├── Makefile │ ├── phase3 │ └── phase4 ├── 1-shell │ ├── ferris-wheel │ ├── getting-started │ ├── stack-vec │ ├── ttywrite │ ├── volatile │ └── xmodem └── os ├── Makefile ├── bootloader ├── kernel ├── pi ├── std └── volatile 

快適で端正な。 0-blinkyおよび1-shellは、以前のラボと現在のラボを指し、 osは次のように取得できます。

 git clone https://web.stanford.edu/class/cs140e/os.git os git checkout master 

すべてが正しく配置されていることを確認し、 os/kernel内でmakeを実行しos/kernel 。 すべてが正常であれば、コマンドは正常に実行されます。

プロジェクト構造

osディレクトリには、次の一連のサブディレクトリが含まれます。

• piは、ドライバーとOS用の低レベルコードを含むライブラリです。
• volatileフェーズ2からの同じ名前のライブラリの2番目のバージョン
• std -Rust標準ライブラリの最小限のスタブ
• bootloader -フェーズ4で追加するブートローダー
• kernel -OSのメインカーネル

すべてのドライバーコードはpiライブラリにあります。 piはvolatileライブラリと（オプションで） stdます。 kernelとbootloaderはpiを使用してデバイスと通信します。 そして、これに加えて、それらはstdに依存していstd 。 volatileは何にも依存しません。 グラフィカルに、この関係は次のようになります。

ファームウェア

続行する前に、ラズベリーファームウェアを更新する必要があります。 これらはすべて、 osディレクトリからmake fetchコマンドでダウンロードできます。 必要な素材をfiles/ロードしfiles/ 。 firmware/bootcode.bin 、 firmware/config.txtおよびfirmware/start.elfをmicroSDカードのルートにコピーしfirmware/bootcode.bin 。 前の部分からact-led-blink.binコピーし、名前をkernel8.imgに変更kernel8.imgます。 したがって、すべてが機能することを確認できます。 そこで、ラズベリー自体の緑色のLEDが点滅します。

更新されたvolatile

osフォルダーにあるこのライブラリーは、フェーズ2で検討したコードとは少し異なります。変更により、デバイスドライバーの作成のコンテキストでこれを少し簡単に使用できるようになります。 主な違いは次のとおりです。

1. UniqueVolatileがUnique<Volatile>置き換えられました
2. Reservedタイプを追加しました。これは絶対に何もできず、スタブとして使用されます

もう1つ、より重要な違いがあります。 ライブラリのすべての型は、 *mut T TではなくTラップします*mut T これにより、ラッピングせずにあらゆる種類の生のアドレスを使用し、次のようにキャストできます0x1000 as *mut Volatile<T> 。 これに加えて、 Volatileラップされたフィールドを含む構造を指定できます。 このようなもの：

 #[repr(C)] struct Registers { REG_A: Volatile<u32>, REG_B: Volatile<u8> } //    .  `Registers`   `0x4000`  . //     `u32`     `u8`      // (. ). let x: *mut Registers = 0x4000 as *mut Registers; //       `unsafe`. //   Rust        unsafe { //   Rust      (*x).REG_A.write(434); let val: u8 = (*x).REG_B.read(); } 

#[repr(C)]とは何ですか？

追記#[repr(C)]は、RustがSmallと同じ方法でメモリ内に構造を形成するように強制します。 これがなければ、Rustにはフィールドの順序とフィールド間のインデントを最適化する権利があります。 生のポインタを使用する場合、ほとんどの場合、メモリ内の特定の構造を意味します。 したがって、 #[repr(C)]使用すると、Rustが想定どおりに構造をメモリに配置することをアサートできます。

コア

os/kernelディレクトリには、OSのカーネルコードの準備が含まれています。 このディレクトリ内のmake呼び出しは、カーネルを収集します。 アセンブリの結果はbuild/サブディレクトリにあります。 このビジネスを開始するには、 build/kernel.binをkernel8.imgという名前でmicroSDカードのルートにコピーbuild/kernel.bin必要があります。 現在、カーネルは何もしていません。 このフェーズの終わりまでに、カーネルにはチャット可能なテキストベースの対話型シェルが含まれます。

kernelラックはpiラックに依存します。 extern crate pi;を見ることができますextern crate pi; kernel/src/kmain.rsに記述しCargo.toml 。 つまり pi宣言されたすべての型と構造を非選択的に使用できます。

ドキュメント

ドライバーを作成するとき、 BCM2837ペリフェラルマニュアルは非常に役立ちます。

サブフェーズB：システムタイマー

このサブフェーズでは、組み込みタイマーのドライバーを作成します。 主な作業は、ファイルos/pi/src/timer.rsおよびos/kernel/src/kmain.rsます。 タイマーは、 BCM2837周辺機器マニュアルの 172ページ（セクション12）に記載されています。

最初に、すでにos/pi/src/timer.rsあるコードを見てos/pi/src/timer.rs 。 少なくともこれらの部分：

 const TIMER_REG_BASE: usize = IO_BASE + 0x3000; #[repr(C)] struct Registers { CS: Volatile<u32>, CLO: ReadVolatile<u32>, CHI: ReadVolatile<u32>, COMPARE: [Volatile<u32>; 4] } pub struct Timer { registers: &'static mut Registers } impl Timer { pub fn new() -> Timer { Timer { registers: unsafe { &mut *(TIMER_REG_BASE as *mut Registers) }, } } } 

最初に注意する必要があるunsafeでunsafeコードの1行があります。 *mut RegistersのアドレスTIMER_REG_BASEはこの行にキャストされ、その後すぐに&'static mut Registersに変わります。 実際、 TIMER_REG_BASEの構造への静的リンクが必要であることをTIMER_REG_BASEています。

TIMER_REG_BASEには正確に何がありますか？ マニュアルの 172ページで、 0x3000がタイマーの周辺の先頭からのオフセットであることがわかります。 つまり TIMER_REG_BASEは、このタイマーのレジスタが始まるアドレスです。 unsafeでunsafe 1行の後に、 registersフィールドを使用して、これらすべてに完全に安全にアクセスできます。 たとえば、 self.registers.CLO.read()をself.registers.CLO.read()てCLOレジスタをself.registers.CLO.read()か、または
self.registers.CS.write()を使用するCS 。

なぜCLOおよびCHIレジスタに書き込めないのですか？ [制限付き読み取り]

BCM2837のドキュメントには、 CLOおよびCHIレジスタが読み取り専用であると記載されています。 コードはこのプロパティを提供します。 どうやって？ 何がCLOとCHI書くことを妨げますか？

安全ではないものは何ですか？

要するに、 unsafeはRustコンパイラーのマーカーであり、ユーザーはメモリーのセキュリティを制御していると言います。 コンパイラーは、これらのコードのメモリー問題からユーザーを保護しません。 コードのunsafe部分では、Rustを使用して、Neat Cで実行できるすべての操作を実行できます。 できる コラバンを奪う あるタイプを別のタイプにキャストし、生のポインターで遊んで、寿命を作成するだけで十分です。

ただし、 unsafeブロック内のコードは非常に危険です。 安全でないセクションで行うことは、実際に安全であることを確認する必要があります。 これは一見思われるよりも複雑です。 特に、Rustのセキュリティ概念は他の言語よりも厳格であるためです。 unsafeでないものを使用しunsafeしてください。 もちろん、可能な範囲で。 オペレーティングシステムなどの場合、機器と直接通信する場合は、 unsafeを使用する必要があります。 ただし、この使用はできる限り制限します。

unsafeモアレを読みたい場合は、Nomiconの第1章をご覧ください 。 さらに、この小さな本を通して、Rustのさまざまな強力な魔術師に役立つ多くのことを学ぶことができます。

ドライバーの実装

os/pi/src/timer.rs Timer::read() os/pi/src/timer.rsからTimer::read()実装しos/pi/src/timer.rs 。 次に、メソッドcurrent_time() 、 spin_sleep_us() 、 spin_sleep_ms()が近くにあります。 これらの関数のコメントと名前は、期待される機能を示しています。 Timer::read()を実装するには、適切なセクションのBCM2837ドキュメントを読む必要がありTimer::read() 。 少なくとも、64ビットタイマー値全体を取得するために読み取る必要があるレジスタを理解する必要があります。 cargo buildして、パイクレートを組み立てることができます。 ただし、 cargo checkを使用して記述された内容の正確性を単純にチェックする方が高速です。

ドライバーテスト

spin_sleep_ms()関数が正しく実装されていることを確認することはspin_sleep_ms()です。 これを行うには、 kernel/src/kmain.rs適切なコードを記述しkernel/src/kmain.rs 。

ゼロラボのフェーズ4からLEDの点滅コードをコピーします。 ループ内でスピンするだけのスリープ関数の代わりに、 spin_sleep_ms()関数を使用して、点滅間の休止を作成する必要があります。 カーネルを再コンパイルし、 kernel8.imgというメモリカードにロードします。 すべてを実行して、計画した頻度でLEDが点滅することを確認します。 別の遅延サイズを設定して、すべてが機能することを確認してください。 はい、microsdカードを常に前後に突くのは非常に面倒です。 このパートの終わりまでに、この問題を解決するブートローダーができます。

タイマーのドライバー実装が機能する場合、次のサブフェーズに進むことができます。

サブフェーズC：GPIO

このサブフェーズでは、特定のピン番号に関係なく、汎用GPIOドライバーを作成します。 主な作業は、ファイルos/pi/src/gpio.rsおよびos/kernel/src/kmain.rsます。 GPIOのドキュメントは、 BCM2837周辺機器マニュアルの 89ページ（セクション6）にあります 。

ステートマシン

すべてのハードウェアデバイスは、本質的にステートマシン （ eng ）と見なすことができます。 それらはある状態で初期化され、他の状態に明示的またはそうではありません。 同時に、デバイスは現在の状態に応じてさまざまな機能を提供します。 つまり、特定の特定の状態では、他の状態への特定の遷移セットのみが動作可能です。

ほとんどのプログラミング言語では、有限状態マシンのセマンティクスを正確に追跡することは不可能です。 しかし、もちろんこれはRustには当てはまりません。 Rustを使用すると、このセマンティクスを非常に明確に追跡できます。 これを使用して、より安全なGPIOドライバーを実装します。 ドライバーは、すべてのGPIOピンが常に正しく使用されるようにします。 コンパイル段階。

* ある種の研究のように見える...

あなたは私を捕まえた。 これは本質的に、現時点での私の研究分野です。 - セルジオ

以下に、GPIOステートマシンプロパティのサブセット（1ピン）の状態図を示します。

私たちの目標は、これらすべてをRustで実装することです。 そもそも、sobsnaは次の図を教えてくれます。

• GPIOはSTART状態からSTARTます
• START状態から、次の状態に移動できます。
  
  1. ALT 、他の状態への遷移はありません
  2. OUTPUT -それ自体への2つの使用可能な遷移： SETおよびCLEAR
  3. INPUT - LEVELという名前の遷移が1つ

ラボ0ではどのようなトランジションを使用しましたか？ [まばたき状態]

Lab 0からフェーズ4のコードを記述したとき、本質的にステートマシンのサブセットを暗黙的に実装しました。 この場合、状態間のどのような遷移が実現しましたか？

Rustタイプシステムを使用して、ピンがOUTPUT状態にある場合にのみSETおよびCLEAR 、 INPUT状態にある場合にLEVELのみが可能であることを保証します。 pi/src/gpio.rsのGPIO構造宣言を見てください：

 pub struct Gpio<State> { pin: u8, registers: &'static mut Registers, _state: PhantomData<State> } 

構造体には、 Stateという一般的な引数が1つあります。 PhantomDataのみが使用し、他のPhantomDataは使用しません。 実際、そのようなPhantomDataのために、構造が何らかの形で一般化された引数を使用していることをRustに納得させるために存在します。 Gpio状態のマーカーとしてStateを使用Gpioます。 同時に、このパラメーターの特定の値を作成できないようにする必要があります。

マクロstate! そこにあると思われる型を生成しますが、作成することはできません。 この場合、 Gpioの状態のリストが生成さGpioます。

 states! { Uninitialized, Input, Output, Alt } //        -  : enum Input { } 

変に見えます 。 可能な値なしで列挙を作成する必要があるのはなぜですか？ 彼らは1つの快適なプロパティがあります。 作成できません。 ただし、マーカーとして使用できます。 Input型の値は作成できないため、だれも渡すことができません。 それらはタイプのレベルでのみ存在し、他のどこにも存在しません。

次に、適切な遷移セットを使用して各状態のメソッドを実装できます。

 impl Gpio<Output> { ///   pub fn set(&mut self) { ... } ///   pub fn clear(&mut self) { ... } } impl Gpio<Input> { ///      pub fn level(&mut self) -> bool { ... } } 

これは、 Gpioが状態に応じて厳密に定義された方法でのみGpioできるという保証のように見えます。 悪くないでしょ？ しかし、これらの状態をどのように達成するのでしょうか？ これを行うには、 Gpio::transition()メソッドがあります。

 impl<T> Gpio<T> { fn transition<S>(self) -> Gpio<S> { Gpio { pin: self.pin, registers: self.registers, _state: PhantomData } } } 

この方法を使用すると、 Gpioをある状態から別の状態に簡単かつ自由に転送できます。 状態T Gpioを取得し、状態S GpioをGpio S すべてのSおよびTで機能することに注意してくださいT このメソッドは非常に慎重に使用する必要があります。 このすべてに間違いを犯した場合、ドライバーは誤って記述されていると見なされます。

transition()を使用するには、 Gpio<S>タイプSを指定する必要があります。 Rustに十分な情報を提供して、Rustがすべて自分で取得できるようにします。 たとえば、 into_outputメソッドの実装：

 pub fn into_output(self) -> Gpio<Output> { self.into_alt(Function::Output).transition() } 

このメソッドでは、戻り値の型がGpio<Output>ことが必要です。 Rust型システムはtransition()呼び出しを調べると、 Gpio::transition()メソッドをGpio<Output>ます。このメソッドはGpio<Output>を返します。 彼は、任意のS存在するGpio<S>を返すメソッドを見つけますS したがって、 S代わりにS Outputを安全に置き換えることができます。 その結果、 Gpio<Alt> （ into_alt関数から）をGpio<Output>に変換します。

クライアントが任意の状態を渡すことができる場合はどうなりますか？ [偽の状態]

ユーザーコードがGpio構造の初期状態を自由に選択できるようにするとどうなるかを考えてください。 何がおかしいのでしょうか？

なぜこれがすべてRustでしかできないのですか？

into_遷移は移動のセマンティクスを使用するという小さな事実に注意してください。 これは、 Gpioが別の状態になるとすぐに、以前の状態ではアクセスできなくなることを意味します。 型がClone 、 Copyおよびその他の複製メソッドを実装するまで、逆遷移は使用できません。 他の言語ではそれができません。 C++でも。 すべての保証付きのコンパイル中のそのような魔術師はここだけです。 （プラスや他の何かの達人は、この声明に挑戦しようとすることができます）

ドライバーの実装

unimplemented!()代わりに必要なコードをすべて書いてunimplemented!()ファイルpi/src/gpio.rs これらすべての方法のコメントと署名から、理解できます 控除を使用して 期待される機能。 ドキュメント（89ページ、 BCM2837マニュアルのセクション6）を参照することは不要です。 cargo checkの有用性を忘れないでcargo check 。

ヒント：中括弧{ ... }を使用して任意の字句スコープを作成できることを忘れないでください。

ドライバーテスト

明らかに、ドライバーをテストするには、 kernel/src/kmain.rsいくつかのコードを書く必要がありkernel/src/kmain.rs 。

今回は、レジスタ自体を直接読み書きする代わりに、LEDを点滅させるためにドライバーを使用します。 GPIOピン番号16をオン/オフすることにより、同時に、コード全体がよりクリーンでエレガントになります。 カーネルをコンパイルし、 kernel8.imgというカードにロードして、 kernel8.imgラズベリーを実行します。 LEDは以前とまったく同じように点滅するはずです。

これで、より多くのLEDを接続できます。 5、6、13、19、26の番号が付けられたGPIOピンを使用します。ゼロラボのピンの番号付きの図を参照して、物理的な位置を確認します。 あなたが望むように多くのLEDでコアを点滅させてください！

どの点滅パターンを選択しましたか？ [LEDパターン]

LEDをオン/オフすることにしたスキームは何ですか？ 好みに合わせて多くのオプションから選択できます。 ただし、選択が厳しい場合は、サークルでオンとオフを切り替えることができます。

GPIOドライバーが完全に動作可能になったら、次のサブフェーズに進むことができます。

サブフェーズD：UART

このサブフェーズでは、ミニUARTデバイスドライバーを作成します。これは、ラズベリーの割合に組み込まれています。 ほとんどの作業は、ファイルos/pi/src/uart.rsおよびos/kernel/src/kmain.rsます。 Mini UARTは、 BCM2837マニュアルの 8ページと10ページ（セクション2.1と2.2）に記載されています 。

UART：ユニバーサル非同期RX / TX

UART （ ru ）またはUniversal Synchronous Reception Transmitterは、腺を2本のワイヤで通信するためのデバイスおよびシリアルプロトコルです。 これらは、CP2102 USBモジュールのUARTデバイスをラズベリーのUARTデバイスに接続するために、ゼロラボのフェーズ1で使用されたものと同じ2つの配線（rx / tx）です。 UARTを介して任意のデータを送信できます。テキスト、バイナリファイル、シール付きの写真など、ファンタジーに十分なものです。 例として、次のサブフェーズで、ラズベリーのUARTから読み取り、CP2102のUARTに書き込む対話型シェルを作成します。 フェーズ4では、ほぼ同じ方法でバイナリ情報を送信します。

UARTプロトコルにはいくつかの構成パラメーターがあります。 すべてが機能するためには、受信機と送信機の両方を同一に構成する必要があります。 これらは次のパラメーターです。

• データサイズ - データを含む1フレームの長さ（8または9ビット）
• パリティビット -データの後にパリティビット（制御ビット）を送信するかどうか
• ストップビット -データが送信されたことを判断するために使用するビット数（1または2ビット）
• ボーレート -ビットレート/秒

Mini UARTはパリティビットをサポートせず、1つのストップビットのみをサポートします。 したがって、ボーレートとフレーム長を設定するだけです。 UART通信の基本 （翻訳が必要ですか？）というドキュメントで、UART自体についてもう少し読むことができます。

ドライバーの実装

この段階では、各ステップをペイントすることなくデバイスドライバーを作成するために必要なすべてのツールが用意されています。 おめでとうございます！

タスクは、必要なすべてをファイルpi/src/uart.rsに実装することです。 Registers構造のコンテンツを追加する必要があります。 この場合、各レジスタに最低限必要な機能のセットを備えた[ Volatileタイプ]オプションを使用します。 これらの読み取り専用レジスタはReadVolatileを使用する必要があります。 WriteVolatileのみWriteVolatile許可されている場合、 WriteVolatile 。 予約スペースにはReservedます。 new() 115200 ( 270) 8 . unimplemented!() , . fmt::Write , io::Read io::Write MiniUart .

: LCR , BAUD CNTL new /

: GPIO .

, ( kernel/src/kmain.rs ), . :

 loop { write_byte(read_byte()) } 

screen /dev/<_> 115200 UART. screen TTY . , . つまり . :

 loop { write_byte(read_byte()) write_str("<-") } 

, — .

E: The Shell

UART . os/kernel/src/console.rs , os/kernel/src/shell.rs os/kernel/src/kmain.rs .

Console

, , - / . Unix stdin stdout . Console . Console kprint! kprintln! 。 , print! println! 。 . Console , .

os/kernel/src/console.rs . Console . - MiniUart . . . MiniUart MiniUart Console .

— , . Rust. Rust . , ? , unsafe . : Rust'y, , .. , "" . , . Rust . :

 //      ! fn make_mut<T>(value: &T) -> &mut T { unsafe { /*      */ } } 

. . , , unsafe Rust. , . " ". つまり . .

, . , . , ( & ). , ( &T -> &mut ).

. , , :

 fn lock<T>(value: &T) -> Locked<&mut T> { unsafe { lock(value); cast value to Locked<&mut T> } } impl Drop for Locked<&mut T> { fn drop(&mut self) { unlock(self.value) } } 

Mutex . — , :

 fn get_mut<T>(value: &T) -> Mut<&mut T> { unsafe { if ref_count(value) != 0 { panic!() } ref_count(value) += 1; cast value to Mut<&mut T> } } impl Drop for Mut<&mut T> { fn drop(&mut self) { ref_count(value) -= 1; } } 

, RefCell::borrow_mut() . — , :

 fn get_mut<T>(value: &T) -> Option<Mut<&mut T>> { unsafe { if ref_count(value) != 0 { None } else { ref_count(value) += 1; Some(cast value to Mut<&mut T>) } } } impl Drop for Mut<&mut T> { fn drop(&mut self) { ref_count(value) -= 1; } } 

RefCell::try_borrow_mut() . " ": . Console Mutex . std::Mutex — . . kernel/src/mutex.rs . , , , Rust. Mutex , , .

だから。 CONSOLE kernel/src/console.rs . kprint! kprintln! , . , Console — Console . CONSOLE Console .

Rust Sync .

T static , T Sync . , Rust . , Rust , . Send Sync , Rust .

** &mut T ? [drop-container]

, , Drop . , &mut T ?

write_fmt ? [write-fmt]

_print write_fmt MutexGuard ( Mutex<Console>::lock() . write_fmt ?

Console

, unimplemented!() kernel/src/console.rs . kprint! kprintln! , kernel/src/kmain.rs , , . , print! println! 。 screen /dev/<-> 115200 .

...

println! — Rust. printf . Rust , , . . , ? .

: Console : .

. kernel/src/shell.rs . Command . Command::parse() Command . parse args StackVec , buf . Command::path() .

( Command , StackVec , Console CONSOLE , kprint! , kprintln! , ) shell . prefix , . "> " . , . ad-infinitum . . echo .

, :

• echo $a $b $c , $a $b $c
• \r \n enter ,
• backspace delete (ASCII 8 127)
• (ASCII 7),
• unknown command: $command $command
• ,
• 512
• 64
• prefix ,
• error: too many arguments

shell . kernel/src/kmain.rs . SOS, , . , . — . .

:

b'a' u8 'a'

\u{b} ASCII b

\r \n

, backspace, , backspace

StackVec

std::str::from_utf8

std !

, std . . , , xargo doc --open os/std .

? [shell-lookback]

. , .

4:

, , Raspberry Pi. os/bootloader/src/kmain.rs

, MicroSD- . , , . , .

— "", , XMODEM UART. , . ttywrite . :

• ttywrite -i -.bin /dev/<->

Raspberyy Pi 3 kernel8.img 0x80000 . , , kernel8.img 0x80000 ARM' (program counter) 0x80000 . , . , 0x80000 .

(linker, ). . : , . , . os/kernel/ext/layout.ld ( ). , 0x80000 . 0x80000 .

, , 0x80000 . . 0x80000 . つまり ! . . . . どうやって？

. os/bootloader/ext/layout.ld , , 0x4000000 . , 0x80000 . kernel_address config.txt . bootloader/ext/config.txt . , . つまり MicroSD-.

0x80000 0x4000000 "" .

63.5 ? [small-kernels]

, , , . — . , . ?

, . macOS - /System/Library/Kernels/kernel . /mach_kernel . Linux - /boot/ vmlinuz , vmlinux bzImage . ? 63.5 ?

bootloader/src/kmain.rs . , , . const . jump_to , addr . . pi xmodem UART, , . , .

, XMODEM, ( 750 ). . — . , — . os/kernel/build/kernel.bin ttywrite . — , screen .

? [bootloader-timeout]

. ?

config.txt , !

:

kmain() 15 .

std::slice::from_raw_parts_mut .

&mut [u8] io::Write .

UPD