Team for GR-PEACH Producer Meeting

メモリマップについて

27 Dec 2014

10MBのメモリを内蔵ということですが、現在のメモリマップとしては全然使えない様になっていると思います。
公開が予定されているLCD Display LibraryでVRAM等として予約しているという可能性もありますが、標準状態でのメモリ割り当てが現在のままではあまり良くないのでは無いかと。

ScatterファイルやStartupコードを見る限り、以下の様になっていると思われます。

RAM PAGELRAM StartLRAM EndSectionAllocate sizeNote
0U0x200000000x200FFFFFLOAD_TTB16KBL1 Translation Table
1U0x201000000x201FFFFFZI_DATA1MBHeap 512KB + Stack 512KB?
2U0x202000000x202FFFFF-Free
3U0x203000000x203FFFFF-Free
4U0x204000000x204FFFFF-Free
0L0x205000000x205FFFFF-Free
1L0x206000000x206FFFFFRW_DATA1MBGlobal variables
2L0x207000000x207FFFFF-Free
3L0x208000000x208FFFFF-Free
4L0x609000000x609FFFFFNC_DATA,NC_BSS1MBNon Cached area

実質1MB程度しか使えるようになってません。
※グローバル変数でchar配列を宣言した場合、領域自体はZI_DATAに確保される
もちろん、自分でアドレスを指定すれば、空き領域を使うことはできますがヒープやスタックに頼らずに使えということを暗に言っているのでしょうか。

また、メモリがたくさんあるからと(信じて)、調子に乗ってローカル変数で1MBの配列を宣言すると、ヒープに食い込みますが、コンパイルエラーにはならないので、お互い壊し合うという状況になります。(2MBとかだともはや動かない)

どうするのが良いのでしょうね。

28 Dec 2014

Akagawaさん
メモリーに関して認識不足でした。気づきを与えていただき、ありがとうございます。
早速、メモリーの勉強をしていくつか気になった点があったので、私もコメントします。
先ず最初の一歩として、メモリー内容を覗くために、以前から他のmbedで使用していたモニタープログラムを改造して表示するようにしました。
下記をコンパイルして、何もIO接続しないGR-PEACHで実行してみてください。

Import programGR-PEACH_memory_check

Monitor program only for mbed GR-PEACH

9600BPSでターミナルソフトを開くと、先ずコンパイラーがエラーとならないぎりぎりのデータバッファーのアドレスを表示しますので、その後メモリーコマンドを入力して各部分を確認できます。
Akagawaさんのコメントのように、ZI_DATA領域にしかグローバル変数が確保できず、今回は、128KBx3+40KB=424KB位が限界です。
これ以上を設定すると、コンパイラーがエラーを吐き出します。
下記のスクリプトファイルに下記の記述がありますが、このファイルはユーザーが書き換えるわけにはいかず、現時点では中の人の考えを聞くしかありません。

MBRZA1H.sct

;省略
    RO_DATA          +0
    { * (+RO-DATA) }              ; Application RO data (.constdata)

    RW_DATA 0x20600000 0x00100000 ; Page 1 of On-Chip Large-Capacity RAM (0x20060000 to 0x206FFFFF)
    { * (+RW) }                   ; Application RW data (.data)

    ZI_DATA 0x20100000 0x00100000 ; Page 1 of On-Chip Large-Capacity RAM (0x20010000 to 0x201FFFFF)
    { * (+ZI) }                   ; Application ZI data (.bss)

    RW_DATA_NC 0x60900000 0x00100000
    { * (NC_DATA) }              ; Application RW data Non cached area
;省略


RZ/A1Hには、同じメモリー領域を別のアドレスから参照できる特徴があります。
0x20???からと0x60???からですが、0x60???はきれいに連続していますので、Page1にこだわらずにもっと広げることが出来そうですが、そう簡単にいかない理由があるのでしょうか?
もう一つ、最初から気になった点が、下記の数値です。
/media/uploads/kenjiArai/memory.png
これはLEDを点滅する一番簡単なソフトですが、611KBのRAMを使っています。
多分、領域を確保しているだけとは思いますが、ここも気にしなくてもよいことですが、気になり始めると眠れません。

まとめ
1) 10MBのRAMをいかにユーザーが自由に使える手段を提供してもらえるか?
   連続で多くの領域を使えないか? 例えば uint8_t databuff[2048*1024];
2) RAMはどのように消費されているのか?
   なぜLED点滅で600KBも使用するのか?

03 Jan 2015

すみません。 グーロバル変数宣言で、大きな配列を定義して使いたのですが、制限に引っかかって、コンパイルできません。

Error: Execution region RW_DATA with Execution range [0x20600000,0x206000f0) overlaps with Execution region ZI_DATA with Execution range [0x20100000,0x20b724b0).

MIDIファイルを再生するサンプルプログラムを移植中ですが、バッファに何MBが必要です。

動的なバッファ制御も可能ですが、移植のレベルを超えるので、まず、オリジナルのソースコードの若干の手直しで、移植を終わらせたいです。

malloc関数を使えば、メモリは、取れるだけとれるのでしょうか?

よろしくお願い致します。

05 Jan 2015

Akagawaさん、Inomataさん、ご報告ありがとうございます。
本件、調査中です。
問題点に登録致しました。
中間報告になると思いますが、1月6日に何かしらの報告を出す予定です。

06 Jan 2015

sctファイルはユーザーで変更できるものと勘違いしておりました。申し訳ありません。
1M以上のRAMを確保できるsctファイルを作成いたしましたが、 webコンパイラ上でsctファイルを変更できないため、 残念ながらCodeで公開することができません。
早急にプルリクエストいたします。

RZ/A1Hは、VRAM領域を大きく取るときなどの場合に、セクションごとにメモリ属性を変更したり、セクションの開始位置を変更したりする必要があります。
単一のsctファイルですべてのシステムに対応することは難しいため、 sctファイルを変更できるようARMに提案中です。

また、blinkyの使用RAM 600KBの内訳ですが、ヒープとスタックです。

用途サイズ
ヒープ524,288
スタック82,688
合計606,976

これらを増減させたいときは、お手数ですが、下記ファイルの該当箇所を変更していただけますでしょうか。
mbed-src\targets\cmsis\TARGET_RENESAS\TARGET_RZ_A1H\TOOLCHAIN_ARM_STD\startup_MBRZA1H.s

ヒープ:(90行目)

Heap_Size       EQU     0x00080000


スタック:(69-74行目、下記の合計)

UND_Stack_Size  EQU     0x00000100
SVC_Stack_Size  EQU     0x00008000
ABT_Stack_Size  EQU     0x00000100
FIQ_Stack_Size  EQU     0x00000100
IRQ_Stack_Size  EQU     0x00008000
USR_Stack_Size  EQU     0x00004000

ヒープで512KB確保しているため、mallocを使用すると512KB弱まではメモリの確保ができます。

よろしくお願いいたします。

07 Jan 2015

1M以上の変数に対応したsctファイルを下記ライブラリに反映させました。
http://developer.mbed.org/teams/GR-PEACH_producer_meeting/code/mbed-src-v442-pre/
お手元のmbed-src-v442-preを置き換えてご利用ください。

12 Jan 2015

一点確認ですが、キャッシュ無効領域はどういう時に使えば良いのでしょうか?
R01AN1754JJ0080には「キャッシュ無効空間にデータ領域を割り当てることにより、投機的キャッシュラインフィルの問題を回避しています。」という記述がありましたが、イマイチ理解できませんでした(というか、そこまで意識しないとダメなんでしょうか)。

13 Jan 2015

>キャッシュ無効領域はどういう時に使えば良いのでしょうか?

現在用意していますライブラリをアプリケーションで制御する場合は使う必要はありませんが、メモリを直接アクセスする周辺I/O(と そのライブラリ)を使用する場合にキャッシュ無効領域を使用します。例えば、現在用意していますEthernetのライブラリ(ライブラリ 内で使用)、また今後用意します画像系のライブラリを使う場合が考えられます。

>「キャッシュ無効空間にデータ領域を割り当てることにより、投機的キャッシュラインフィルの問題を回避しています。」という記述がありましたが、イマイチ理解できませんでした。

キャッシュはCPUに付属しています。
DMAなどの周辺機能でメモリにアクセスする場合、キャッシュを経由せずにメモリをアクセスします。
CPUでメモリ書き込みを行ったつもりでも、書き込んだデータはキャッシュ上のみで、実メモリに反映されていないことがあります。
このような場合にDMAなどのキャッシュを経由しないでメモリアクセスする機能を使用すると、DMAで転送されるデータが変更前の値になってしまうことがあり得ます。
/media/uploads/RyoheiHagimoto/dma_read.png
また、反対にDMAで転送されたデータを読むときも同様のことが言えます。
/media/uploads/RyoheiHagimoto/dma_write.png
このような問題を「投機的キャッシュラインフィルの問題」といいます。
上記のような動作を避けたい場合、キャッシュ無効空間を使うことがあります。

13 Jan 2015

解説ありがとうございます。これの事をそう呼ぶんですね。知りませんでした。
A9はマルチコア対応なので、その辺はCPUなりキャッシュコントローラがよしなにやってくれるのかと思ってました。
※Cortex-M7はどうなるんだろう。気になる...