[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 06/11] riscv: Initial commit of OpenTitan machine
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v5 06/11] riscv: Initial commit of OpenTitan machine |
Date: |
Tue, 9 Jun 2020 16:21:09 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 6/9/20 3:48 PM, Damien Hedde wrote:
>
> Hi Alistair,
>
> On 5/29/20 12:14 AM, Alistair Francis wrote:
>> This adds a barebone OpenTitan machine to QEMU.
>>
>> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
>> Reviewed-by: Bin Meng <bin.meng@windriver.com>
>> ---
>
>> diff --git a/include/hw/riscv/opentitan.h b/include/hw/riscv/opentitan.h
>> new file mode 100644
>> index 0000000000..a4b6499444
>> --- /dev/null
>> +++ b/include/hw/riscv/opentitan.h
>> @@ -0,0 +1,68 @@
>
> [...]
>
>> +
>> +static const struct MemmapEntry {
>> + hwaddr base;
>> + hwaddr size;
>> +} ibex_memmap[] = {
>> + [IBEX_ROM] = { 0x00008000, 0xc000 },
>
> Shouldn't the ROM size be 0x4000 (which make the end of rom at 0xc000) ?
>
> Not sure if that's exactly this platform you are modeling but the
> following doc says the ROM size is 16kB (0x4000):
> https://github.com/lowRISC/opentitan/blob/master/hw/top_earlgrey/doc/_index.md
Good catch. This is why I prefer the IEC notation:
[IBEX_ROM] = { 0x00008000, 16 * KiB },
You can then verify the mapping running 'info mtree' in the monitor.
>
> --
> Damien
>
>