MMC対応カーネル Ver.1.23の「update/フォントデータの再配置の方法.txt」にも書かれているとおり、MMC対応カーネルインストール時に実行する「make font2」がハングアップしてしまいます。 この症状は、フラッシュメモリ書き込みプログラム「ku」の不具合が原因のようです。 具体的に言いますと、「ku」は0xC10000よりも後ろのアドレスのフラッシュメモリを書き換えた場合、カーネルプログラムに関係ないと判断して、書き換え後のリセットを行わないようです。 ここで「ku」は、フラッシュメモリ書き換え前にマスク不可割り込みを停止しているのですけれど、書き換え終了後にマスク不可割り込みを再開させるのを忘れてしまっています。 通常のカーネルアップデート(0xC02000〜の書き換え)の場合は、書き換え後にリセットが行われるため、再起動処理の中でマスク不可割り込みが再開し、正しくP/ECEが動き出します。 ところが今回問題となった「make font2」は、0xC10000よりも後ろの書き換えなので、リセットが行われず、そのままマスク不可割り込みが禁止されたままとなって、ハングアップしてしまいます。 リセットするかしないかの判断基準のアドレス「0xC10000」は、きっちりカーネル領域の終端を示しているのではなく、だいたい0xC10000より後ぐらいならばカーネルプログラムとは関係ないかな〜という感じで決められているみたいです。 もう一方のフォントインストール手順「make font1」は、たまたま0xC10000よりも前だったために、カーネルアップデートと同様のリセットが行われて、ハングアップしなかったみたいです。
対処方法は次のとおりです。書き換えアドレスにかかわらず、常に書き換え後リセットを行うように変更してみました。
● sysdev/ku/fwr.c 202行目
[変更前]
nores = ( pfh->top_adrs >= 0xc10000 );
[変更後]
// nores = ( pfh->top_adrs >= 0xc10000 ); コメントアウトしました
変更後、ku.srfを更新するために、sysdev/ku/フォルダで「make clean」と「make」を行ってください。
MMC対応カーネル Ver.1.23は、カーネルプログラムサイズが増えたために、10x10全角フォントを通常のカーネルよりも少し後ろへずらしています。
通常のカーネルでは、10x10全角フォントは0xC0C000〜に配置されるのですけれど、MMC対応カーネルでは、0xC0D000〜に変更となっています。
8x16半角フォントと4x6半角フォントの位置は通常カーネルと同じで、8x16半角フォント:0xC26000〜、4x6半角フォント:0xC27000〜です。
ところが10x10全角フォントの総サイズは106246バイトあるため、0xC0D000〜0xC26F05・・・8x16半角フォント領域にかぶってしまっています。
「make font1」だけだと8x16半角フォントが崩れるのは、これが原因だったみたいです。
MMC対応カーネル Ver.1.23のインストール手順では、「make font1」の後に「make font2」を行うので、10x10全角フォントの後ろの方が8x16半角フォントで少し上書きされてしまっていることになります。
たとえば、次のようなプログラムを実行してみると、10x10全角フォントの一部が崩れていることがわかります。
/* シフトJISです */ #include <piece.h> unsigned char vbuff[128 * 88]; void pceAppInit() { pceLCDSetBuffer(vbuff); pceLCDDispStart(); } void pceAppProc(int count) { memset(vbuff, 0, sizeof vbuff); pceFontSetType(0); pceFontSetPos(0, 0); pceFontPutStr("井上瑤"); pceLCDTrans(); } void pceAppExit() { }▼通常のカーネルで実行した場合
8x16半角フォントと4x6半角フォントはとても小さいので、二つ合わせてフラッシュメモリ1セクタ(4KB)以内に収まります。 そこで、10x10全角フォント領域は0xC0D000〜0xC26FFFとし、8x16半角フォントと4x6半角フォントをくっつけて0xC27000〜0xC27FFFの領域に配置します。 具体的には、8x16半角フォント:0xC27000〜、4x6半角フォント:0xC27600〜、となりました。
変更点は次のとおりです。