From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
Alistair Francis <alistair23@gmail.com>,
Laszlo Ersek <lersek@redhat.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
Palmer Dabbelt <palmer@sifive.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bmeng.cn@gmail.com>
Subject: Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
Date: Tue, 24 Sep 2019 11:32:14 +0200 [thread overview]
Message-ID: <16bab4bf-b91e-ef0c-2d22-53538f74cfc4@redhat.com> (raw)
In-Reply-To: <CAFEAcA-uFPGf4BiDXH=Om3Df-xXrt7QwjzVF7E3kY4aMWMP4YQ@mail.gmail.com>
On 9/23/19 11:46 PM, Peter Maydell wrote:
> On Fri, 20 Sep 2019 at 23:23, Alistair Francis <alistair23@gmail.com> wrote:
>> On Thu, Sep 19, 2019 at 10:15 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>> I don't think we should mirror what is used on ARM virt board to
>>> create 2 flash for sifive_u. For ARM virt, there are 2 flashes because
>>> they need distinguish secure and non-secure. For sifive_u, only one is
>>> enough.
>>
>> I went back and forward about 1 or 2. Two seems more usable as maybe
>> someone wants to include two pflash files? The Xilinx machine also has
>> two so I'm kind of used to 2, but I'm not really fussed.
The Xilinx machine has 2 because it matches the hardware.
> One of the reasons for having 2 on the Arm board (we do this
> even if we're not supporting secure vs non-secure) is that
> then you can use one for a fixed read-only BIOS image (backed
> by a file on the host filesystem shared between all VMs), and
> one backed by a read-write per-VM file providing permanent
> storage for BIOS environment variables. Notably UEFI likes to
> work this way, but the idea applies in theory to other
> boot loader or BIOSes I guess.
IIRC Laszlo's explanation, the only reason it is that way is because the
pflash_cfi01 model still doesn't implement sector locking. At the OVMF
emerged from EDK2, to have a safe ROM vs DATA storage it was decided to
use 2 different flashes.
When I understood when this config layout started, I suggested Laszlo to
use a real ROM to store the OVMF CODE since it is pointless to do
firmware upgrade in virtualized environment, but he said it was too late
to change the design.
If you don't plan to run UEFI "Capsule Update" on your Virt board, I
suggest using memory_region_init_rom() with your firmware CODE, and a
parallel/SPI flash for the data VARStore.
> I would suggest also checking with Markus that your code
> for instantiating the flash devices follows the current
> recommendations so the backing storage can be configured
> via -blockdev. (This is a fairly recent change from June or
> so; current-in-master virt and sbsa boards provide an example
> of doing the right thing, I think.)
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2019-09-24 9:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 22:24 [PATCH v1 0/6] RISC-V: Add more machine memory Alistair Francis
2019-09-19 22:24 ` [PATCH v1 1/6] riscv/sifive_u: Add L2-LIM cache memory Alistair Francis
2019-09-20 5:15 ` Bin Meng
2019-09-19 22:24 ` [PATCH v1 2/6] riscv/sifive_u: Add QSPI memory region Alistair Francis
2019-09-20 5:15 ` Bin Meng
2019-09-19 22:25 ` [PATCH v1 3/6] riscv/sifive_u: Manually define the machine Alistair Francis
2019-09-20 5:15 ` Bin Meng
2019-09-19 22:25 ` [PATCH v1 4/6] riscv/sifive_u: Add the start-in-flash property Alistair Francis
2019-09-20 5:15 ` Bin Meng
2019-09-20 22:07 ` Alistair Francis
2019-09-22 2:19 ` Bin Meng
2019-09-23 17:51 ` Alistair Francis
2019-09-24 0:57 ` Bin Meng
2019-09-19 22:25 ` [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device Alistair Francis
2019-09-20 5:15 ` Bin Meng
2019-09-20 22:12 ` Alistair Francis
2019-09-22 2:15 ` Bin Meng
2019-09-23 20:08 ` Alistair Francis
2019-09-23 21:46 ` Peter Maydell
2019-09-24 9:32 ` Philippe Mathieu-Daudé [this message]
2019-09-24 17:12 ` Laszlo Ersek
2019-09-25 0:55 ` Alistair Francis
2019-09-25 11:15 ` Philippe Mathieu-Daudé
2019-09-25 0:54 ` Alistair Francis
2019-09-25 9:00 ` Markus Armbruster
2019-09-27 21:49 ` Alistair Francis
2019-09-19 22:25 ` [PATCH v1 6/6] riscv/virt: Jump to pflash if specified Alistair Francis
2019-09-20 5:15 ` Bin Meng
2019-09-23 9:09 ` Philippe Mathieu-Daudé
2019-09-20 22:40 ` [PATCH v1 0/6] RISC-V: Add more machine memory Palmer Dabbelt
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=16bab4bf-b91e-ef0c-2d22-53538f74cfc4@redhat.com \
--to=philmd@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=armbru@redhat.com \
--cc=bmeng.cn@gmail.com \
--cc=lersek@redhat.com \
--cc=palmer@sifive.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).