All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernhard Beschow <shentey@gmail.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	"Bin Meng" <bin.meng@windriver.com>,
	qemu-ppc <qemu-ppc@nongnu.org>
Subject: Re: [PATCH 07/11] hw/ppc/e500: Implement pflash handling
Date: Fri, 16 Sep 2022 17:05:13 +0000	[thread overview]
Message-ID: <056AAA77-0631-43DA-B1B0-7DD73A87BD72@gmail.com> (raw)
In-Reply-To: <CAEUhbmUzss14vX0GeB8GgB1n2YTzai5sKsYno_qzh68fXixqXA@mail.gmail.com>

Am 16. September 2022 15:00:06 UTC schrieb Bin Meng <bmeng.cn@gmail.com>:
>On Thu, Sep 15, 2022 at 11:36 PM Bernhard Beschow <shentey@gmail.com> wrote:
>>
>> Allows e500 boards to have their root file system reside on flash using
>> only builtin devices.
>>
>> Note that the flash memory area is only created when a -pflash argument is
>> given, and that the size is determined by the given file. The idea is to
>> put users into control.
>>
>> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> ---
>>  docs/system/ppc/ppce500.rst | 12 +++++++++
>>  hw/ppc/Kconfig              |  1 +
>>  hw/ppc/e500.c               | 54 +++++++++++++++++++++++++++++++++++++
>>  3 files changed, 67 insertions(+)
>>
>> diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst
>> index ba6bcb7314..c3f55c6f3d 100644
>> --- a/docs/system/ppc/ppce500.rst
>> +++ b/docs/system/ppc/ppce500.rst
>> @@ -119,6 +119,18 @@ To boot the 32-bit Linux kernel:
>>        -initrd /path/to/rootfs.cpio \
>>        -append "root=/dev/ram"
>>
>> +Rather than using a root file system on ram disk, it is possible to have it on
>> +emulated flash. Given an ext2 image whose size must be a power of two, it can
>> +be used as follows:
>> +
>> +.. code-block:: bash
>> +
>> +  $ qemu-system-ppc64 -M ppce500 -cpu e500mc -smp 4 -m 2G \
>
>qemu-system-ppc{64|32}

Will fix.

>> +      -display none -serial stdio \
>> +      -kernel vmlinux \
>> +      -drive if=pflash,file=/path/to/rootfs.ext2,format=raw \
>> +      -append "rootwait root=/dev/mtdblock0"
>> +
>>  Running U-Boot
>>  --------------
>>
>> diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
>> index 791fe78a50..769a1ead1c 100644
>> --- a/hw/ppc/Kconfig
>> +++ b/hw/ppc/Kconfig
>> @@ -126,6 +126,7 @@ config E500
>>      select ETSEC
>>      select GPIO_MPC8XXX
>>      select OPENPIC
>> +    select PFLASH_CFI01
>>      select PLATFORM_BUS
>>      select PPCE500_PCI
>>      select SERIAL
>> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
>> index 864b6f3d92..7843a4e04b 100644
>> --- a/hw/ppc/e500.c
>> +++ b/hw/ppc/e500.c
>> @@ -23,8 +23,10 @@
>>  #include "e500-ccsr.h"
>>  #include "net/net.h"
>>  #include "qemu/config-file.h"
>> +#include "hw/block/flash.h"
>>  #include "hw/char/serial.h"
>>  #include "hw/pci/pci.h"
>> +#include "sysemu/block-backend-io.h"
>>  #include "sysemu/sysemu.h"
>>  #include "sysemu/kvm.h"
>>  #include "sysemu/reset.h"
>> @@ -267,6 +269,34 @@ static void sysbus_device_create_devtree(SysBusDevice *sbdev, void *opaque)
>>      }
>>  }
>>
>> +static void create_devtree_flash(SysBusDevice *sbdev,
>> +                                 PlatformDevtreeData *data)
>> +{
>> +    char *name;
>
>Use g_autofree

Yes, good idea.

>> +    uint64_t num_blocks = object_property_get_uint(OBJECT(sbdev),
>> +                                                   "num-blocks",
>> +                                                   &error_fatal);
>> +    uint64_t sector_length = object_property_get_uint(OBJECT(sbdev),
>> +                                                      "sector-length",
>> +                                                      &error_fatal);
>> +    uint64_t bank_width = object_property_get_uint(OBJECT(sbdev),
>> +                                                   "width",
>> +                                                   &error_fatal);
>> +    hwaddr flashbase = 0;
>> +    hwaddr flashsize = num_blocks * sector_length;
>> +    void *fdt = data->fdt;
>> +
>> +    name = g_strdup_printf("%s/nor@%" PRIx64, data->node, flashbase);
>> +    qemu_fdt_add_subnode(fdt, name);
>> +    qemu_fdt_setprop_cell(fdt, name, "#address-cells", 1);
>> +    qemu_fdt_setprop_cell(fdt, name, "#size-cells", 1);
>
>#address-cells and #size-cells are not needed.

Will remove.

>> +    qemu_fdt_setprop_string(fdt, name, "compatible", "cfi-flash");
>> +    qemu_fdt_setprop_sized_cells(fdt, name, "reg",
>> +                                 1, flashbase, 1, flashsize);
>> +    qemu_fdt_setprop_cell(fdt, name, "bank-width", bank_width);
>> +    g_free(name);
>> +}
>> +
>>  static void platform_bus_create_devtree(PPCE500MachineState *pms,
>>                                          void *fdt, const char *mpic)
>>  {
>> @@ -276,6 +306,8 @@ static void platform_bus_create_devtree(PPCE500MachineState *pms,
>>      uint64_t addr = pmc->platform_bus_base;
>>      uint64_t size = pmc->platform_bus_size;
>>      int irq_start = pmc->platform_bus_first_irq;
>> +    SysBusDevice *sbdev;
>> +    bool ambiguous;
>>
>>      /* Create a /platform node that we can put all devices into */
>>
>> @@ -302,6 +334,13 @@ static void platform_bus_create_devtree(PPCE500MachineState *pms,
>>      /* Loop through all dynamic sysbus devices and create nodes for them */
>>      foreach_dynamic_sysbus_device(sysbus_device_create_devtree, &data);
>>
>> +    sbdev = SYS_BUS_DEVICE(object_resolve_path_type("", TYPE_PFLASH_CFI01,
>> +                                                    &ambiguous));
>
>Can this be moved into sysbus_device_create_devtree(), and use the
>same logic as the eTSEC device?

I've tried that, but the logic for eTSEC seems to get triggered for user-created devices only. Since TYPE_PFLASH_CFI01 isn't user-created we're not triggered I guess.

I think that the eTSEC handling could be moved into sysbus-fdt.c but I'm not sure whether this is allowed due to poisoning.

>> +    if (sbdev) {
>> +        assert(!ambiguous);
>> +        create_devtree_flash(sbdev, &data);
>> +    }
>> +
>>      g_free(node);
>>  }
>>
>> @@ -856,6 +895,7 @@ void ppce500_init(MachineState *machine)
>>      unsigned int pci_irq_nrs[PCI_NUM_PINS] = {1, 2, 3, 4};
>>      IrqLines *irqs;
>>      DeviceState *dev, *mpicdev;
>> +    DriveInfo *dinfo;
>>      CPUPPCState *firstenv = NULL;
>>      MemoryRegion *ccsr_addr_space;
>>      SysBusDevice *s;
>> @@ -1024,6 +1064,20 @@ void ppce500_init(MachineState *machine)
>>                                  pmc->platform_bus_base,
>>                                  sysbus_mmio_get_region(s, 0));
>>
>> +    dinfo = drive_get(IF_PFLASH, 0, 0);
>> +    if (dinfo) {
>> +        BlockBackend *blk = blk_by_legacy_dinfo(dinfo);
>> +        BlockDriverState *bs = blk_bs(blk);
>> +        uint64_t size = bdrv_getlength(bs);
>> +        if (ctpop64(size) != 1) {
>> +            error_report("Size of pflash file must be a power of two.");
>> +            exit(1);
>> +        }
>
>I think we should also check whether the flash size plus the eTSEC
>size exceeds the platform bus mmio window size otherwise it won't work
>for both devices present, no?

I could check that the flash fits inside the eLBC memory window.

For user-created devices such as eTSEC, however, I'd like to rely on other parts of QEMU to check this. First, I don't know how to get access to all relevant devices and their memory windows, and second, catching all possible (future) cases here seems a bit ad-hoc and fragile to me.

Best regards,
Bernhard
>
>> +        pflash_cfi01_register(pmc->platform_bus_base, "e500.flash",
>> +                              size, blk,
>> +                              64 * KiB, 2, 0x89, 0x18, 0x0000, 0x0, 1);
>> +    }
>> +
>>      /*
>>       * Smart firmware defaults ahead!
>>       *
>
>Regards,
>Bin



  reply	other threads:[~2022-09-16 17:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-15 15:25 [PATCH 00/11] ppc/e500: Add support for two types of flash, cleanup Bernhard Beschow
2022-09-15 15:25 ` [PATCH 01/11] hw/ppc/meson: Allow e500 boards to be enabled separately Bernhard Beschow
2022-09-16  2:37   ` Bin Meng
2022-09-18 12:15   ` Philippe Mathieu-Daudé via
2022-09-15 15:25 ` [PATCH 02/11] hw/gpio/meson: Introduce dedicated config switch for hw/gpio/mpc8xxx Bernhard Beschow
2022-09-16  2:40   ` Bin Meng
2022-09-18 12:15   ` Philippe Mathieu-Daudé via
2022-09-15 15:25 ` [PATCH 03/11] docs/system/ppc/ppce500: Add heading for networking chapter Bernhard Beschow
2022-09-16  2:43   ` Bin Meng
2022-09-18 12:16   ` Philippe Mathieu-Daudé via
2022-09-15 15:25 ` [PATCH 04/11] hw/ppc/mpc8544ds: Add platform bus Bernhard Beschow
2022-09-16  6:15   ` Bin Meng
2022-09-16 17:19     ` Bernhard Beschow
2022-10-09  2:31       ` Bin Meng
2022-09-15 15:25 ` [PATCH 05/11] hw/ppc/e500: Remove if statement which is now always true Bernhard Beschow
2022-09-16  6:17   ` Bin Meng
2022-09-18 12:17   ` Philippe Mathieu-Daudé via
2022-09-15 15:25 ` [PATCH 06/11] hw/block/pflash_cfi01: Error out if device length isn't a power of two Bernhard Beschow
2022-09-16  6:24   ` Bin Meng
2022-09-15 15:25 ` [PATCH 07/11] hw/ppc/e500: Implement pflash handling Bernhard Beschow
2022-09-16 15:00   ` Bin Meng
2022-09-16 17:05     ` Bernhard Beschow [this message]
2022-10-03 19:45       ` B
2022-09-15 15:25 ` [PATCH 08/11] hw/sd/sdhci-internal: Unexport ESDHC defines Bernhard Beschow
2022-09-16 10:04   ` Bin Meng
2022-09-18 12:19   ` Philippe Mathieu-Daudé via
2022-09-15 15:25 ` [PATCH 09/11] hw/sd/sdhci: Rename ESDHC_* defines to USDHC_* Bernhard Beschow
2022-09-16 10:07   ` Bin Meng
2022-09-16 17:11     ` Bernhard Beschow
2022-09-15 15:25 ` [PATCH 10/11] hw/sd/sdhci: Implement Freescale eSDHC device model Bernhard Beschow
2022-09-16 15:15   ` Bin Meng
2022-09-16 17:27     ` Bernhard Beschow
2022-09-15 15:25 ` [PATCH 11/11] hw/ppc/e500: Add Freescale eSDHC to e500 boards Bernhard Beschow
2022-09-16 15:26   ` Bin Meng
2022-09-16 16:15     ` Bernhard Beschow
2022-09-16 15:27 ` [PATCH 00/11] ppc/e500: Add support for two types of flash, cleanup Bin Meng
2022-09-16 16:08   ` Bernhard Beschow
2022-09-18 14:37 ` Philippe Mathieu-Daudé via

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=056AAA77-0631-43DA-B1B0-7DD73A87BD72@gmail.com \
    --to=shentey@gmail.com \
    --cc=bin.meng@windriver.com \
    --cc=bmeng.cn@gmail.com \
    --cc=f4bug@amsat.org \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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.