yanagihara
2014年9月10日 11時17分
こんにちは、柳原と申します。
hermit-at-win32(v2.1.5とv2.2.0で確認)で、任意のregionをeraseした後
downloadした時にフラッシュに書き込まれる値について質問があります。
downloadするimageファイルのbyteサイズが4で割り切れない場合、書き込み後
のフラッシュにおけるimageファイル末尾位置以降に、4から4の剰余を引いた
値に相当するサイズの不定値が書き込まれるようですが、これは何ですか？
例えば、userlandに6122193バイトのromfs.img.gzを書き込むと、以下の様に
3バイトのff以外の値(30 12 74)が書き込まれていました。この部分はeraseに
よるffで埋められていると期待していました。
元ファイル (クロス開発環境で確認)：
$ hexdump -v -e '"%07.7_ax" 16/1 " %02X" "\n"' -s 6122176 -n 32 romfs.img.gz 05d6ac0 73 45 6C 65 63 74 72 69 63 00 56 41 45 00 00 26 05d6ad0 26
フラッシュ (Armadillo-440にログインして確認)：
# hexdump -v -e '"%07.7_ax" 16/1 " %02X" "\n"' -s 6122176 -n 32 /dev/flash/userland 05d6ac0 73 45 6C 65 63 74 72 69 63 00 56 41 45 00 00 26 05d6ad0 26 30 12 74 FF FF FF FF FF FF FF FF FF FF FF FF
コメント
yanagihara
at_makoto.harada
原田です。
情報ありがとうございます。頂いた情報をもとに少し調べてみました。
a4x0用Hermit-AtのNOR Flashプログラム機能は、ドライバ(flash_intel.c)の仕様で32
bit 単位(WORD PROGRAM)もしくは16 bit 単位(BUFFER PROGRAM)で書き込みを行います。
>例えば、userlandに6122193バイトのromfs.img.gzを書き込むと、以下の様に
>3バイトのff以外の値(30 12 74)が書き込まれていました。この部分はeraseに
>よるffで埋められていると期待していました。
PCからArmadilloにダウンロードしたデータのサイズ(nbytes)が32bit単位でない場合、フ
ラッシュにプログラムする直前で下記のコードにて切り上げしています。サイズを切り上げ
た分、ダウンロードしたデータのサイズとフラッシュに書き込みするデータサイズにギャップ
が生じ、ゴミデータが書き込まれているようです。
# src/host/common/download.c
#define UNALIGNED_BITS 3
static tsize_t download_to_flash(...)
{
....
/* download into flash programming buffer */
do_download(tc, data, nbytes, DD_BUF, 0);
/* program one buffer's worth (may not be a complete block) */
abytes = nbytes;
if (abytes & UNALIGNED_BITS)
abytes = (abytes + UNALIGNED_BITS) & ~UNALIGNED_BITS;
/* program at lma, not vma (current address, not canonical) */
snprintf(cmdbuf, sizeof cmdbuf, "program 0x%08lx %ld",
(unsigned long) (vma - block_mr->vma + block_mr->lma),
(long) abytes);
target_write_command(tc, cmdbuf);
....
}>質問の症状はhermit-at-win32では発生しますが、Armadillo-440のブートロー
>ダからtftpdlコマンドを実行してフラッシュ書き換えを行った場合は不定値は
>付加されませんでした。
tftpdlの場合は、以下のようにpadding処理をしていますね。
# src/target/command/tftp_common.c
static int program_file(struct tftp_file *file)
{
....
if (programed + blksize > filesize) {
int padding;
u8 *buf;
blksize = filesize - programed;
padding = ((blksize % 4) ? (4 - (blksize % 4)) : 0);
buf = (u8 *)(file->data.base + filesize);
for (i=0; i<padding; i++)
*buf++ = 0xff;
blksize += padding;
}
...
ret = flash_program(src, dst, blksize);
}
yanagihara
2014年9月17日 16時39分
こんにちは、柳原です。
追加情報です。
質問の症状はhermit-at-win32では発生しますが、Armadillo-440のブートロー
ダからtftpdlコマンドを実行してフラッシュ書き換えを行った場合は不定値は
付加されませんでした。
> downloadするimageファイルのbyteサイズが4で割り切れない場合、書き込み後
> のフラッシュにおけるimageファイル末尾位置以降に、4から4の剰余を引いた
> 値に相当するサイズの不定値が書き込まれるようですが、これは何ですか？
「これは何ですか？」と質問しておりますが、本当に知りたい点は、
linux.bin、linux.bin.gz、romfs.img、romfs.img.gzのバイトサイズが4で割
り切れるようにすれば本症状を回避できると断言できるかどうかです。
フラッシュROMの全領域(all)をEraseした上で、ブートローダとlinux.bin.gz
とromfs.img.gzの書き込みを行った後、MD5ダイジェストによるベリファイを
行いたいのですが、本症状のためMD5ダイジェストが期待値と一致しません。
対策として、linux.bin、linux.bin.gz、romfs.img、romfs.img.gzのバイトサ
イズが4で割り切れるようにダミー領域を付加する事自体は既にできているの
ですが、これが対策として妥当かどうかを知りたいのです。