Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Wed, Sep 25, 2019 at 2:00 AM Markus Armbruster wrote: > > Alistair Francis writes: > > > On Mon, Sep 23, 2019 at 2:46 PM Peter Maydell > > wrote: > >> > >> On Fri, 20 Sep 2019 at 23:23, Alistair Francis > >> wrote: > >> > On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. > >> > >> 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. > > > > This seems like a good reason to have two and there isn't really a > > disadvantage so I have kept it with two. > > Good. > > Implementing sector locking would be even better. I'm not asking you to > do that work. > > >> 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.) > > > > I have updated the code to more closely match the ARM virt machine, so > > I think I'm doing it correctly. > > You might want to consider omitting legacy configuration options -drive > if=pflash and -bios for a simpler interface. We just moved to -bios and it's been really helpful. Doesn't -pflash use -drive if=pflash? How else should these be attached? Alistair
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On 9/25/19 2:55 AM, Alistair Francis wrote: > On Tue, Sep 24, 2019 at 2:32 AM Philippe Mathieu-Daudé > wrote: >> >> On 9/23/19 11:46 PM, Peter Maydell wrote: >>> On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. > > We might run that one day, who knows :) You certainly want to run EDK2, I'm following RISCV progress on the list. What doesn't make sense on a virtualized platform is the "Capsule Update" feature IMO. Where it makes sense is on the SiFive E/U boards models. >>> 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 >>>
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
Alistair Francis writes: > On Mon, Sep 23, 2019 at 2:46 PM Peter Maydell > wrote: >> >> On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: >> > On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. >> >> 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. > > This seems like a good reason to have two and there isn't really a > disadvantage so I have kept it with two. Good. Implementing sector locking would be even better. I'm not asking you to do that work. >> 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.) > > I have updated the code to more closely match the ARM virt machine, so > I think I'm doing it correctly. You might want to consider omitting legacy configuration options -drive if=pflash and -bios for a simpler interface.
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Tue, Sep 24, 2019 at 2:32 AM Philippe Mathieu-Daudé wrote: > > On 9/23/19 11:46 PM, Peter Maydell wrote: > > On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: > >> On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. We might run that one day, who knows :) Alistair > > > 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 > >
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Mon, Sep 23, 2019 at 2:46 PM Peter Maydell wrote: > > On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: > > On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. > > 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. This seems like a good reason to have two and there isn't really a disadvantage so I have kept it with two. > > 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.) I have updated the code to more closely match the ARM virt machine, so I think I'm doing it correctly. Alistair > > thanks > -- PMM
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On 09/24/19 11:32, Philippe Mathieu-Daudé wrote: > On 9/23/19 11:46 PM, Peter Maydell wrote: >> On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: >>> On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. Right, at that point I couldn't see how "-bios" *plus* "-pflash" could have worked. In chronological order (for OVMF anyway), there was -bios, then -pflash (R/W), then (with some QEMU changes) two -pflash flags (R/O + R/W, which OVMF wouldn't tell apart from the single R/W -pflash). Thanks Laszlo > > 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 >>
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On 9/23/19 11:46 PM, Peter Maydell wrote: > On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: >> On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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 >
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Fri, 20 Sep 2019 at 23:23, Alistair Francis wrote: > On Thu, Sep 19, 2019 at 10:15 PM Bin Meng 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. 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. 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
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Sat, Sep 21, 2019 at 7:15 PM Bin Meng wrote:
>
> On Sat, Sep 21, 2019 at 6:16 AM Alistair Francis wrote:
> >
> > On Thu, Sep 19, 2019 at 10:15 PM Bin Meng wrote:
> > >
> > > On Fri, Sep 20, 2019 at 6:36 AM Alistair Francis
> > > wrote:
> > > >
> > > > Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
> > > > from the ARM Virt board and the implementation is based on the ARM Virt
> > > > board. This allows users to specify flash files from the command line.
> > > >
> > > > Signed-off-by: Alistair Francis
> > > > ---
> > > > hw/riscv/Kconfig| 1 +
> > > > hw/riscv/virt.c | 81 +
> > > > include/hw/riscv/virt.h | 3 ++
> > > > 3 files changed, 85 insertions(+)
> > > >
> > > > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > > > index fb19b2df3a..b12660b9f8 100644
> > > > --- a/hw/riscv/Kconfig
> > > > +++ b/hw/riscv/Kconfig
> > > > @@ -36,4 +36,5 @@ config RISCV_VIRT
> > > > select SERIAL
> > > > select VIRTIO_MMIO
> > > > select PCI_EXPRESS_GENERIC_BRIDGE
> > > > +select PFLASH_CFI01
> > > > select SIFIVE
> > > > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > > > index d36f5625ec..ca002ecea7 100644
> > > > --- a/hw/riscv/virt.c
> > > > +++ b/hw/riscv/virt.c
> > > > @@ -26,6 +26,7 @@
> > > > #include "hw/boards.h"
> > > > #include "hw/loader.h"
> > > > #include "hw/sysbus.h"
> > > > +#include "hw/qdev-properties.h"
> > > > #include "hw/char/serial.h"
> > > > #include "target/riscv/cpu.h"
> > > > #include "hw/riscv/riscv_hart.h"
> > > > @@ -61,12 +62,72 @@ static const struct MemmapEntry {
> > > > [VIRT_PLIC] ={ 0xc00, 0x400 },
> > > > [VIRT_UART0] = { 0x1000, 0x100 },
> > > > [VIRT_VIRTIO] = { 0x10001000,0x1000 },
> > > > +[VIRT_FLASH] = { 0x2000, 0x200 },
> > > > [VIRT_DRAM] ={ 0x8000, 0x0 },
> > > > [VIRT_PCIE_MMIO] = { 0x4000,0x4000 },
> > > > [VIRT_PCIE_PIO] ={ 0x0300,0x0001 },
> > > > [VIRT_PCIE_ECAM] = { 0x3000,0x1000 },
> > > > };
> > > >
> > > > +#define VIRT_FLASH_SECTOR_SIZE (256 * KiB)
> > > > +
> > > > +static PFlashCFI01 *virt_flash_create1(RISCVVirtState *s,
> > > > + const char *name,
> > > > + const char *alias_prop_name)
> > > > +{
> > > > +/*
> > > > + * Create a single flash device. We use the same parameters as
> > > > + * the flash devices on the ARM virt board.
> > > > + */
> > > > +DeviceState *dev = qdev_create(NULL, TYPE_PFLASH_CFI01);
> > > > +
> > > > +qdev_prop_set_uint64(dev, "sector-length", VIRT_FLASH_SECTOR_SIZE);
> > > > +qdev_prop_set_uint8(dev, "width", 4);
> > > > +qdev_prop_set_uint8(dev, "device-width", 2);
> > > > +qdev_prop_set_bit(dev, "big-endian", false);
> > > > +qdev_prop_set_uint16(dev, "id0", 0x89);
> > > > +qdev_prop_set_uint16(dev, "id1", 0x18);
> > > > +qdev_prop_set_uint16(dev, "id2", 0x00);
> > > > +qdev_prop_set_uint16(dev, "id3", 0x00);
> > > > +qdev_prop_set_string(dev, "name", name);
> > >
> > > alias_prop_name is unused? ARM virt has 2 more calls in the same function
> > > here.
> >
> > Yep, you are right. I have removed this.
>
> Any reason of removing this?
The way the virt machine was structured didn't work with the options.
I have fixed that in v2 of the series.
Alistair
>
> >
> > >
> > > > +
> > > > +return PFLASH_CFI01(dev);
> > > > +}
> > > > +
> > > > +static void virt_flash_create(RISCVVirtState *s)
> > > > +{
> > > > +s->flash[0] = virt_flash_create1(s, "virt.flash0", "pflash0");
> > > > +s->flash[1] = virt_flash_create1(s, "virt.flash1", "pflash1");
> > >
> > > 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.
> >
> > Unless anyone else wants two I will change it to 1.
>
> Regards,
> Bin
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Sat, Sep 21, 2019 at 6:16 AM Alistair Francis wrote:
>
> On Thu, Sep 19, 2019 at 10:15 PM Bin Meng wrote:
> >
> > On Fri, Sep 20, 2019 at 6:36 AM Alistair Francis
> > wrote:
> > >
> > > Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
> > > from the ARM Virt board and the implementation is based on the ARM Virt
> > > board. This allows users to specify flash files from the command line.
> > >
> > > Signed-off-by: Alistair Francis
> > > ---
> > > hw/riscv/Kconfig| 1 +
> > > hw/riscv/virt.c | 81 +
> > > include/hw/riscv/virt.h | 3 ++
> > > 3 files changed, 85 insertions(+)
> > >
> > > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > > index fb19b2df3a..b12660b9f8 100644
> > > --- a/hw/riscv/Kconfig
> > > +++ b/hw/riscv/Kconfig
> > > @@ -36,4 +36,5 @@ config RISCV_VIRT
> > > select SERIAL
> > > select VIRTIO_MMIO
> > > select PCI_EXPRESS_GENERIC_BRIDGE
> > > +select PFLASH_CFI01
> > > select SIFIVE
> > > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > > index d36f5625ec..ca002ecea7 100644
> > > --- a/hw/riscv/virt.c
> > > +++ b/hw/riscv/virt.c
> > > @@ -26,6 +26,7 @@
> > > #include "hw/boards.h"
> > > #include "hw/loader.h"
> > > #include "hw/sysbus.h"
> > > +#include "hw/qdev-properties.h"
> > > #include "hw/char/serial.h"
> > > #include "target/riscv/cpu.h"
> > > #include "hw/riscv/riscv_hart.h"
> > > @@ -61,12 +62,72 @@ static const struct MemmapEntry {
> > > [VIRT_PLIC] ={ 0xc00, 0x400 },
> > > [VIRT_UART0] = { 0x1000, 0x100 },
> > > [VIRT_VIRTIO] = { 0x10001000,0x1000 },
> > > +[VIRT_FLASH] = { 0x2000, 0x200 },
> > > [VIRT_DRAM] ={ 0x8000, 0x0 },
> > > [VIRT_PCIE_MMIO] = { 0x4000,0x4000 },
> > > [VIRT_PCIE_PIO] ={ 0x0300,0x0001 },
> > > [VIRT_PCIE_ECAM] = { 0x3000,0x1000 },
> > > };
> > >
> > > +#define VIRT_FLASH_SECTOR_SIZE (256 * KiB)
> > > +
> > > +static PFlashCFI01 *virt_flash_create1(RISCVVirtState *s,
> > > + const char *name,
> > > + const char *alias_prop_name)
> > > +{
> > > +/*
> > > + * Create a single flash device. We use the same parameters as
> > > + * the flash devices on the ARM virt board.
> > > + */
> > > +DeviceState *dev = qdev_create(NULL, TYPE_PFLASH_CFI01);
> > > +
> > > +qdev_prop_set_uint64(dev, "sector-length", VIRT_FLASH_SECTOR_SIZE);
> > > +qdev_prop_set_uint8(dev, "width", 4);
> > > +qdev_prop_set_uint8(dev, "device-width", 2);
> > > +qdev_prop_set_bit(dev, "big-endian", false);
> > > +qdev_prop_set_uint16(dev, "id0", 0x89);
> > > +qdev_prop_set_uint16(dev, "id1", 0x18);
> > > +qdev_prop_set_uint16(dev, "id2", 0x00);
> > > +qdev_prop_set_uint16(dev, "id3", 0x00);
> > > +qdev_prop_set_string(dev, "name", name);
> >
> > alias_prop_name is unused? ARM virt has 2 more calls in the same function
> > here.
>
> Yep, you are right. I have removed this.
Any reason of removing this?
>
> >
> > > +
> > > +return PFLASH_CFI01(dev);
> > > +}
> > > +
> > > +static void virt_flash_create(RISCVVirtState *s)
> > > +{
> > > +s->flash[0] = virt_flash_create1(s, "virt.flash0", "pflash0");
> > > +s->flash[1] = virt_flash_create1(s, "virt.flash1", "pflash1");
> >
> > 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.
>
> Unless anyone else wants two I will change it to 1.
Regards,
Bin
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Thu, Sep 19, 2019 at 10:15 PM Bin Meng wrote:
>
> On Fri, Sep 20, 2019 at 6:36 AM Alistair Francis
> wrote:
> >
> > Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
> > from the ARM Virt board and the implementation is based on the ARM Virt
> > board. This allows users to specify flash files from the command line.
> >
> > Signed-off-by: Alistair Francis
> > ---
> > hw/riscv/Kconfig| 1 +
> > hw/riscv/virt.c | 81 +
> > include/hw/riscv/virt.h | 3 ++
> > 3 files changed, 85 insertions(+)
> >
> > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > index fb19b2df3a..b12660b9f8 100644
> > --- a/hw/riscv/Kconfig
> > +++ b/hw/riscv/Kconfig
> > @@ -36,4 +36,5 @@ config RISCV_VIRT
> > select SERIAL
> > select VIRTIO_MMIO
> > select PCI_EXPRESS_GENERIC_BRIDGE
> > +select PFLASH_CFI01
> > select SIFIVE
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index d36f5625ec..ca002ecea7 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -26,6 +26,7 @@
> > #include "hw/boards.h"
> > #include "hw/loader.h"
> > #include "hw/sysbus.h"
> > +#include "hw/qdev-properties.h"
> > #include "hw/char/serial.h"
> > #include "target/riscv/cpu.h"
> > #include "hw/riscv/riscv_hart.h"
> > @@ -61,12 +62,72 @@ static const struct MemmapEntry {
> > [VIRT_PLIC] ={ 0xc00, 0x400 },
> > [VIRT_UART0] = { 0x1000, 0x100 },
> > [VIRT_VIRTIO] = { 0x10001000,0x1000 },
> > +[VIRT_FLASH] = { 0x2000, 0x200 },
> > [VIRT_DRAM] ={ 0x8000, 0x0 },
> > [VIRT_PCIE_MMIO] = { 0x4000,0x4000 },
> > [VIRT_PCIE_PIO] ={ 0x0300,0x0001 },
> > [VIRT_PCIE_ECAM] = { 0x3000,0x1000 },
> > };
> >
> > +#define VIRT_FLASH_SECTOR_SIZE (256 * KiB)
> > +
> > +static PFlashCFI01 *virt_flash_create1(RISCVVirtState *s,
> > + const char *name,
> > + const char *alias_prop_name)
> > +{
> > +/*
> > + * Create a single flash device. We use the same parameters as
> > + * the flash devices on the ARM virt board.
> > + */
> > +DeviceState *dev = qdev_create(NULL, TYPE_PFLASH_CFI01);
> > +
> > +qdev_prop_set_uint64(dev, "sector-length", VIRT_FLASH_SECTOR_SIZE);
> > +qdev_prop_set_uint8(dev, "width", 4);
> > +qdev_prop_set_uint8(dev, "device-width", 2);
> > +qdev_prop_set_bit(dev, "big-endian", false);
> > +qdev_prop_set_uint16(dev, "id0", 0x89);
> > +qdev_prop_set_uint16(dev, "id1", 0x18);
> > +qdev_prop_set_uint16(dev, "id2", 0x00);
> > +qdev_prop_set_uint16(dev, "id3", 0x00);
> > +qdev_prop_set_string(dev, "name", name);
>
> alias_prop_name is unused? ARM virt has 2 more calls in the same function
> here.
Yep, you are right. I have removed this.
>
> > +
> > +return PFLASH_CFI01(dev);
> > +}
> > +
> > +static void virt_flash_create(RISCVVirtState *s)
> > +{
> > +s->flash[0] = virt_flash_create1(s, "virt.flash0", "pflash0");
> > +s->flash[1] = virt_flash_create1(s, "virt.flash1", "pflash1");
>
> 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.
Unless anyone else wants two I will change it to 1.
Alistair
>
> > +}
> > +
> > +static void virt_flash_map1(PFlashCFI01 *flash,
> > +hwaddr base, hwaddr size,
> > +MemoryRegion *sysmem)
> > +{
> > +DeviceState *dev = DEVICE(flash);
> > +
> > +assert(size % VIRT_FLASH_SECTOR_SIZE == 0);
> > +assert(size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
> > +qdev_prop_set_uint32(dev, "num-blocks", size / VIRT_FLASH_SECTOR_SIZE);
> > +qdev_init_nofail(dev);
> > +
> > +memory_region_add_subregion(sysmem, base,
> > +sysbus_mmio_get_region(SYS_BUS_DEVICE(dev),
> > + 0));
> > +}
> > +
> > +static void virt_flash_map(RISCVVirtState *s,
> > + MemoryRegion *sysmem)
> > +{
> > +hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
> > +hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
> > +
> > +virt_flash_map1(s->flash[0], flashbase, flashsize,
> > +sysmem);
> > +virt_flash_map1(s->flash[1], flashbase + flashsize, flashsize,
> > +sysmem);
> > +}
> > +
> > static void create_pcie_irq_map(void *fdt, char *nodename,
> > uint32_t plic_phandle)
> > {
> > @@ -121,6 +182,8 @@
Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device
On Fri, Sep 20, 2019 at 6:36 AM Alistair Francis
wrote:
>
> Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
> from the ARM Virt board and the implementation is based on the ARM Virt
> board. This allows users to specify flash files from the command line.
>
> Signed-off-by: Alistair Francis
> ---
> hw/riscv/Kconfig| 1 +
> hw/riscv/virt.c | 81 +
> include/hw/riscv/virt.h | 3 ++
> 3 files changed, 85 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index fb19b2df3a..b12660b9f8 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -36,4 +36,5 @@ config RISCV_VIRT
> select SERIAL
> select VIRTIO_MMIO
> select PCI_EXPRESS_GENERIC_BRIDGE
> +select PFLASH_CFI01
> select SIFIVE
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index d36f5625ec..ca002ecea7 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -26,6 +26,7 @@
> #include "hw/boards.h"
> #include "hw/loader.h"
> #include "hw/sysbus.h"
> +#include "hw/qdev-properties.h"
> #include "hw/char/serial.h"
> #include "target/riscv/cpu.h"
> #include "hw/riscv/riscv_hart.h"
> @@ -61,12 +62,72 @@ static const struct MemmapEntry {
> [VIRT_PLIC] ={ 0xc00, 0x400 },
> [VIRT_UART0] = { 0x1000, 0x100 },
> [VIRT_VIRTIO] = { 0x10001000,0x1000 },
> +[VIRT_FLASH] = { 0x2000, 0x200 },
> [VIRT_DRAM] ={ 0x8000, 0x0 },
> [VIRT_PCIE_MMIO] = { 0x4000,0x4000 },
> [VIRT_PCIE_PIO] ={ 0x0300,0x0001 },
> [VIRT_PCIE_ECAM] = { 0x3000,0x1000 },
> };
>
> +#define VIRT_FLASH_SECTOR_SIZE (256 * KiB)
> +
> +static PFlashCFI01 *virt_flash_create1(RISCVVirtState *s,
> + const char *name,
> + const char *alias_prop_name)
> +{
> +/*
> + * Create a single flash device. We use the same parameters as
> + * the flash devices on the ARM virt board.
> + */
> +DeviceState *dev = qdev_create(NULL, TYPE_PFLASH_CFI01);
> +
> +qdev_prop_set_uint64(dev, "sector-length", VIRT_FLASH_SECTOR_SIZE);
> +qdev_prop_set_uint8(dev, "width", 4);
> +qdev_prop_set_uint8(dev, "device-width", 2);
> +qdev_prop_set_bit(dev, "big-endian", false);
> +qdev_prop_set_uint16(dev, "id0", 0x89);
> +qdev_prop_set_uint16(dev, "id1", 0x18);
> +qdev_prop_set_uint16(dev, "id2", 0x00);
> +qdev_prop_set_uint16(dev, "id3", 0x00);
> +qdev_prop_set_string(dev, "name", name);
alias_prop_name is unused? ARM virt has 2 more calls in the same function here.
> +
> +return PFLASH_CFI01(dev);
> +}
> +
> +static void virt_flash_create(RISCVVirtState *s)
> +{
> +s->flash[0] = virt_flash_create1(s, "virt.flash0", "pflash0");
> +s->flash[1] = virt_flash_create1(s, "virt.flash1", "pflash1");
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.
> +}
> +
> +static void virt_flash_map1(PFlashCFI01 *flash,
> +hwaddr base, hwaddr size,
> +MemoryRegion *sysmem)
> +{
> +DeviceState *dev = DEVICE(flash);
> +
> +assert(size % VIRT_FLASH_SECTOR_SIZE == 0);
> +assert(size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
> +qdev_prop_set_uint32(dev, "num-blocks", size / VIRT_FLASH_SECTOR_SIZE);
> +qdev_init_nofail(dev);
> +
> +memory_region_add_subregion(sysmem, base,
> +sysbus_mmio_get_region(SYS_BUS_DEVICE(dev),
> + 0));
> +}
> +
> +static void virt_flash_map(RISCVVirtState *s,
> + MemoryRegion *sysmem)
> +{
> +hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
> +hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
> +
> +virt_flash_map1(s->flash[0], flashbase, flashsize,
> +sysmem);
> +virt_flash_map1(s->flash[1], flashbase + flashsize, flashsize,
> +sysmem);
> +}
> +
> static void create_pcie_irq_map(void *fdt, char *nodename,
> uint32_t plic_phandle)
> {
> @@ -121,6 +182,8 @@ static void create_fdt(RISCVVirtState *s, const struct
> MemmapEntry *memmap,
> char *nodename;
> uint32_t plic_phandle, phandle = 1;
> int i;
> +hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
> +hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
>
> fdt = s->fdt = create_device_tree(>fdt_size);
> if (!fdt) {
> @@ -316,6 +379,15 @@ static void create_fdt(RISCVVirtState *s, const struct
> MemmapEntry *memmap,
> qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", cmdline);
> }
> g_free(nodename);
> +
> +nodename =
