
前回の続き。Spike-ISSには通常のDRAM以外に別のメモリが貼り付けられていることが分かった。
今回焦点を当てたいのは0x1000に貼り付けられているROMらしきものだ。sim.ccには、以下のような記述でROMが生成されていた。
uint32_t reset_vec[8] = { 0x297 + DRAM_BASE - DEFAULT_RSTVEC, // reset vector 0x00028067, // jump straight to DRAM_BASE 0x00000000, // reserved 0, // config string pointer 0, 0, 0, 0 // trap vector }; reset_vec[3] = DEFAULT_RSTVEC + sizeof(reset_vec); // config string pointer config_string = s.str(); rom.insert(rom.end(), config_string.begin(), config_string.end()); rom.resize((rom.size() / align + 1) * align); boot_rom.reset(new rom_device_t(rom)); bus.add_device(DEFAULT_RSTVEC, boot_rom.get());
config_stringは--dump-config-stringで出てくるアレだ。
platform {
vendor ucb;
arch spike;
};
rtc {
addr 0x40000000;
};
ram {
0 {
addr 0x80000000;
size 0xaef00000;
};
};
core {
0 {
0 {
isa rv64imafdc;
timecmp 0x40000008;
ipi 0x40001000;
};
};
};
ただし、その前に4byte x8=32byteほど、特殊な情報が貼り付けられている。reset_vecで定義されているところだ。
ダンプしてみると以下のようになる。
7ffff29f 00028067 00000000 00001020 00000000 00000000 00000000 00000000
なるほど、0x100cを参照したときに返された値はこの0x1020だったのか。これは分からない。。。
という訳でROM領域を急遽実装した。
- module_rom.cpp
MemResult ModuleRom::LoadData (Addr_t addr, Size_t size, Word_t *data)
{
memcpy (data, &m_memory[addr], size);
m_env->DebugPrint ("<ROM: Load (%08x)=>%08x, %d\n", addr, *data, size);
m_env->GetTrace()->RecordTraceMemRead (addr, *data, Size_Word);
return MemResult::MemNoExcept;
}
ModuleRom::ModuleRom (EnvBase *env, FILE *dbgfp)
{
m_env = env;
uint32_t init[8] = {0x7ffff29f,
0x00028067,
0x00000000,
0x00001020,
0x00000000,
0x00000000,
0x00000000,
0x00000000};
for (int i = 0; i < 8; i++) {
memcpy (&m_memory[i*4], &init[i], 4);
}
}
とりあえず問題の場所は解決しt。次にまだSpikeと一致しないところがあるから直さないと。。。