All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Michael Clark <mjc@sifive.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Palmer Dabbelt <palmer@sifive.com>
Subject: Re: [Qemu-devel] [PATCH v1 1/4] hw/riscv/sifive_u: Create a U54 SoC object
Date: Mon, 7 May 2018 13:26:52 -0700	[thread overview]
Message-ID: <CAKmqyKP=d36zZkBnSmUXbC0QY=keQ0VMrOJvxX52y57rb1YekQ@mail.gmail.com> (raw)
In-Reply-To: <CAHNT7NuaUV8jX8p6yjEXNYqtRHmYPSFFN23xr=Lr=-fnMneBZw@mail.gmail.com>

On Fri, May 4, 2018 at 3:55 PM, Michael Clark <mjc@sifive.com> wrote:
>
>
> On Sat, May 5, 2018 at 8:12 AM, Alistair Francis <alistair.francis@wdc.com>
> wrote:
>>
>> Create a SiFive Unleashed U54 SoC and use that in the sifive_u machine.
>>
>> We leave the SoC, RAM, device tree and reset/fdt loading as part of the
>> machine. All the other device creation has been moved to the SoC.
>
>
> There is a tiny problem that we will have to resolve with renaming,
> otherwise we will end up with lots of SOCs that are the essentially same
> with a different CPU.
>
> There is an intention to add a HiFive1 and HiFiveU board in the future
> however we were very explicit in renaming sifive_e300 and sifive_u500 to
> sifive_e and sifive_u.
>
> If you read the code more closely you'll notice that we instantiate the
> sifive_u board with a U34 if 32-bit and a U54 if 64-bit.
>
> #if defined(TARGET_RISCV32)
> #define SIFIVE_U_CPU TYPE_RISCV_CPU_SIFIVE_U34
> #elif defined(TARGET_RISCV64)
> #define SIFIVE_U_CPU TYPE_RISCV_CPU_SIFIVE_U54
> #endif
>
> The rationale is that sifive_e and sifive_u can eventually be customized to
> represent different configurations of SiFive Core IP. We won't want to end
> up hardcoding specific models in sifive_e or sifive_u
>
> SiFive have been talking internally about having sifive_e and sifive_u
> reconfigurable, possibly even to the extend where we can configure with a
> memory map. This is somewhat consistent with what SiFive do internally as
> the FE310 and FU540 are configurations generated by a core generator.
>
> Now comes the question of whether its the right time to add a 'hifive1' or
> 'hifiveu' machine. I don't think it is immediately necessary. The thought
> being that we would be able to give a configuration string of file to
> sifive_u e.g. "e51,u54,u54,u54". There is a different between the U54 and
> the U54-MC which has an E51 core for management tasks. The PLIC has already
> been written with this in mind, and is re-configurable to support the U54-MC
> memory layout.

Aren't the E51, U54, U54-MC, etc. all different SoCs? So doesn't it
make sense to break out the SoCs and then in future the user can
specify the SoC for the machine/board when they start QEMU?

Alistair

>
> In anycase. The change is simply to use sifive_u_soc or sifive_u without the
> 54 (given it configures with a U34 in 32-bit like the sifive_e configures
> with an E51 in 64-bit mode, both valid configurations)
>

  reply	other threads:[~2018-05-07 20:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04 20:12 [Qemu-devel] [PATCH v1 0/4] RISC-V: SoCify the SiFive boards and connect the Alistair Francis
2018-05-04 20:12 ` [Qemu-devel] [PATCH v1 1/4] hw/riscv/sifive_u: Create a U54 SoC object Alistair Francis
2018-05-04 22:55   ` Michael Clark
2018-05-07 20:26     ` Alistair Francis [this message]
2018-05-04 20:13 ` [Qemu-devel] [PATCH v1 2/4] hw/riscv/sifive_plic: Use gpios instead of irqs Alistair Francis
2018-05-10  2:33   ` Philippe Mathieu-Daudé
2018-05-10 17:40     ` Alistair Francis
2018-05-04 20:13 ` [Qemu-devel] [PATCH v1 3/4] hw/riscv/sifive_u: Connect the Cadence GEM Ethernet device Alistair Francis
2018-05-04 20:13 ` [Qemu-devel] [PATCH v1 4/4] hw/riscv/sifive_e: Create a E31 SoC object Alistair Francis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKmqyKP=d36zZkBnSmUXbC0QY=keQ0VMrOJvxX52y57rb1YekQ@mail.gmail.com' \
    --to=alistair23@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=mjc@sifive.com \
    --cc=palmer@sifive.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.