ここで公開してくれていることはとってもためになります。
http://www.saturn.dti.ne.jp/~hsakai/kozos/h8_04.html
筆者の試行錯誤の連続の様子が伺えます。
いろいろ分からないことがありますが、ここで１つ記憶しておくとしたら以下です。
（以下抜粋）
モトローラSフォーマットについて調べてみたのだけど， 実は以下のような利点がある．(uuencode形式を選択したのは，単に実装がラクそう だったから)
テキスト形式なので，回線が7bitだったらどうとかフロー制御のコードがあったら どうとか余計なことを考えなくていい．
データを受信しながらそのままメモリ上に展開する，という処理に向いている．
それと筆者坂井さんの２つのファイルフォーマットの解釈の記述は印象に残ります。
このようなことまで記述してくれることはありがたいことです。
●モトローラＳレコード形式の特徴について。
（以下抜粋）
今回ブートローダーを作っていて， 「データをバッファ上に一度読み込んでからロードアドレスに展開するのではなく， データを読み込みながら展開先を調べて直接ロードできないか？」 という疑問があった．というのは，いったんどこかのバッファに置いてから ロード先にコピーするような動作だと，処理自体は楽なのだけど，まあワーク領域と して倍のメモリを使うことになるので，今回のマイコンボードのようにRAMが少ない 場合には，問題となるからだ．(結局，今はいったんバッファに置く実装になっている ので，これは将来課題ではある)
で，上のような問題意識があったうえでフォーマットを調べていたからこそ今回 気がついたことなのだが，モトローラSフォーマットというのは，データを読み込み ながらロード先のメモリ上に直接展開するのに非常に向いている． というのは，ロード先のアドレスが先頭にあるので，まずアドレスを読んで， 後続のデータをそのアドレスの指す先に配置していけばいいからだ．うーん， きっとこういうことを考えた上で作られたフォーマットなんだろうなあ．
●ELF形式の特徴について。
（以下抜粋）
ELF形式というのも，まあモトローラSフォーマットほどやりやすくは無いが， プログラムヘッダが先頭付近にあるため，読み込みながら直接展開，ということは 原理的にはできる(プログラムヘッダがファイルの終端にあったりすると，最後まで 読まないとロード先がわからないので，直接展開は原理的に不可能)．
この記事からもわかるのだけど， ELF形式は先頭付近にプログラムヘッダ，末尾にセクションヘッダが配置されており， プログラムのロードはプログラムヘッダを参照して行われるが、リンク作業はセクションヘッダを参照して行われる． なぜこのような配置になっているのか今までとっても疑問だったのだけど， おそらくプログラムヘッダが先頭付近にあるのは上記のようにプログラムを読み込みしながら展開先に直接展開するためだ．あとセクションヘッダが終端にあるのは， これもおそらくだけど，プログラムのロード＆実行にはセクションヘッダは 必要無いので，サイズ節約のために実行形式から取り除きたい場合がある． この場合，ファイルの先頭付近にあると，そこを削除すると後続のデータの オフセットが変わってしまうため，様々なオフセット計算をやり直さなければ ならなくなってこれはそうとう面倒臭い．しかし終端にあれば，単にそれを 取り除くだけでいいからだ，と思う．
ところで、ELF形式の特徴を知った後、あるロジックを思い出した。
あそこ作った人、ELF形式を知ってそれをそのまま流用したんだろうなぁ（笑）。
http://www.saturn.dti.ne.jp/~hsakai/kozos/h8_04.html
筆者の試行錯誤の連続の様子が伺えます。
いろいろ分からないことがありますが、ここで１つ記憶しておくとしたら以下です。
（以下抜粋）
モトローラSフォーマットについて調べてみたのだけど， 実は以下のような利点がある．(uuencode形式を選択したのは，単に実装がラクそう だったから)
テキスト形式なので，回線が7bitだったらどうとかフロー制御のコードがあったら どうとか余計なことを考えなくていい．
データを受信しながらそのままメモリ上に展開する，という処理に向いている．
それと筆者坂井さんの２つのファイルフォーマットの解釈の記述は印象に残ります。
このようなことまで記述してくれることはありがたいことです。
●モトローラＳレコード形式の特徴について。
（以下抜粋）
今回ブートローダーを作っていて， 「データをバッファ上に一度読み込んでからロードアドレスに展開するのではなく， データを読み込みながら展開先を調べて直接ロードできないか？」 という疑問があった．というのは，いったんどこかのバッファに置いてから ロード先にコピーするような動作だと，処理自体は楽なのだけど，まあワーク領域と して倍のメモリを使うことになるので，今回のマイコンボードのようにRAMが少ない 場合には，問題となるからだ．(結局，今はいったんバッファに置く実装になっている ので，これは将来課題ではある)
で，上のような問題意識があったうえでフォーマットを調べていたからこそ今回 気がついたことなのだが，モトローラSフォーマットというのは，データを読み込み ながらロード先のメモリ上に直接展開するのに非常に向いている． というのは，ロード先のアドレスが先頭にあるので，まずアドレスを読んで， 後続のデータをそのアドレスの指す先に配置していけばいいからだ．うーん， きっとこういうことを考えた上で作られたフォーマットなんだろうなあ．
●ELF形式の特徴について。
（以下抜粋）
ELF形式というのも，まあモトローラSフォーマットほどやりやすくは無いが， プログラムヘッダが先頭付近にあるため，読み込みながら直接展開，ということは 原理的にはできる(プログラムヘッダがファイルの終端にあったりすると，最後まで 読まないとロード先がわからないので，直接展開は原理的に不可能)．
この記事からもわかるのだけど， ELF形式は先頭付近にプログラムヘッダ，末尾にセクションヘッダが配置されており， プログラムのロードはプログラムヘッダを参照して行われるが、リンク作業はセクションヘッダを参照して行われる． なぜこのような配置になっているのか今までとっても疑問だったのだけど， おそらくプログラムヘッダが先頭付近にあるのは上記のようにプログラムを読み込みしながら展開先に直接展開するためだ．あとセクションヘッダが終端にあるのは， これもおそらくだけど，プログラムのロード＆実行にはセクションヘッダは 必要無いので，サイズ節約のために実行形式から取り除きたい場合がある． この場合，ファイルの先頭付近にあると，そこを削除すると後続のデータの オフセットが変わってしまうため，様々なオフセット計算をやり直さなければ ならなくなってこれはそうとう面倒臭い．しかし終端にあれば，単にそれを 取り除くだけでいいからだ，と思う．
ところで、ELF形式の特徴を知った後、あるロジックを思い出した。
あそこ作った人、ELF形式を知ってそれをそのまま流用したんだろうなぁ（笑）。