public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
To: Simon Glass <sjg@chromium.org>
Cc: nd@arm.com, u-boot@lists.denx.de
Subject: Re: [PATCH v1 6/6] sandbox64: add a test case for UCLASS_NVMXIP
Date: Mon, 17 Apr 2023 10:21:43 +0100	[thread overview]
Message-ID: <20230417092143.GA42378@e130802.arm.com> (raw)
In-Reply-To: <CAPnjgZ2Cap69PyGjxHzqegsQXg-XNSYJQ5unWwdSUaKf5PMdgw@mail.gmail.com>

On Mon, Feb 06, 2023 at 09:02:40PM -0700, Simon Glass wrote:
> Hi,
> 
> On Mon, 16 Jan 2023 at 10:29, <abdellatif.elkhlifi@arm.com> wrote:
> >
> > From: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
> >
> > provide a test for NVM XIP devices
> >
> > The test case allows to make sure of the following:
> >
> > - The NVM XIP QSPI devices are probed
> > - The DT entries are read correctly
> > - the data read from the flash by the NVMXIP block driver is correct
> >
> > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
> > ---
> >  MAINTAINERS      |   1 +
> >  test/dm/Makefile |   5 ++
> >  test/dm/nvmxip.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 123 insertions(+)
> >  create mode 100644 test/dm/nvmxip.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 539d01f68c..e92898e462 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1199,6 +1199,7 @@ S:        Maintained
> >  F:     doc/develop/driver-model/nvmxip.rst
> >  F:     doc/device-tree-bindings/nvmxip/nvmxip.txt
> >  F:     drivers/nvmxip/
> > +F:     test/dm/nvmxip.c
> >
> >  NVMEM
> >  M:     Sean Anderson <seanga2@gmail.com>
> > diff --git a/test/dm/Makefile b/test/dm/Makefile
> > index 7a79b6e1a2..7f9d0b3c38 100644
> > --- a/test/dm/Makefile
> > +++ b/test/dm/Makefile
> > @@ -1,6 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0+
> >  #
> >  # Copyright (c) 2013 Google, Inc
> > +# Copyright 2023 Arm Limited and/or its affiliates <open-source-office@arm.com>
> >
> >  obj-$(CONFIG_UT_DM) += test-dm.o
> >
> > @@ -17,6 +18,10 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
> >  obj-$(CONFIG_UT_DM) += core.o
> >  obj-$(CONFIG_UT_DM) += read.o
> >  obj-$(CONFIG_UT_DM) += phys2bus.o
> > +ifeq ($(CONFIG_NVMXIP_QSPI)$(CONFIG_SANDBOX64),yy)
> > +obj-y += nvmxip.o
> > +endif
> > +
> >  ifneq ($(CONFIG_SANDBOX),)
> >  ifeq ($(CONFIG_ACPIGEN),y)
> >  obj-y += acpi.o
> > diff --git a/test/dm/nvmxip.c b/test/dm/nvmxip.c
> > new file mode 100644
> > index 0000000000..b65154d125
> > --- /dev/null
> > +++ b/test/dm/nvmxip.c
> > @@ -0,0 +1,117 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Functional tests for UCLASS_FFA  class
> > + *
> > + * Copyright 2023 Arm Limited and/or its affiliates <open-source-office@arm.com>
> > + *
> > + * Authors:
> > + *   Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
> > + */
> > +
> > +#include <common.h>
> > +#include <console.h>
> > +#include <blk.h>
> > +#include <dm.h>
> > +#include <dm/test.h>
> > +#include "../../drivers/nvmxip/nvmxip.h"
> 
> move to end
> 
> > +#include <test/test.h>
> > +#include <test/ut.h>
> > +
> > +/* NVMXIP devices described in the device tree  */
> > +#define SANDBOX_NVMXIP_DEVICES 2
> > +
> > +/* reference device tree data for the probed devices */
> > +static struct nvmxip_plat nvmqspi_refdata[SANDBOX_NVMXIP_DEVICES] = {
> > +       {0x08000000, 9, 4096}, {0x08200000, 9, 2048}
> > +};
> > +
> > +#define NVMXIP_BLK_START_PATTERN 0x1122334455667788ULL
> > +#define NVMXIP_BLK_END_PATTERN 0xa1a2a3a4a5a6a7a8ULL
> > +
> > +static int dm_nvmxip_flash_sanity(u8 device_idx, void *buffer)
> > +{
> > +       int i;
> > +       u64 *ptr = NULL;
> > +       u8 *base = NULL;
> > +       unsigned long blksz;
> > +
> > +       blksz = 1 << nvmqspi_refdata[device_idx].lba_shift;
> 
> BIT() or BITUL() ?
> 
> > +
> > +       /* if buffer not NULL, init the flash with the pattern data*/
> 
> space before */   (please fix globally)
> 
> can you explain why, in the comment?
> 
> > +       if (!buffer)
> > +               base = map_sysmem(nvmqspi_refdata[device_idx].phys_base, 0);
> > +       else
> > +               base = buffer;
> > +
> > +       for (i = 0; i < nvmqspi_refdata[device_idx].lba ; i++) {
> > +               ptr = (u64 *)(base + i * blksz);
> > +
> > +               /* write an 8 bytes pattern at the start of the current block*/
> > +               if (!buffer)
> > +                       *ptr = NVMXIP_BLK_START_PATTERN;
> > +               else if (*ptr != NVMXIP_BLK_START_PATTERN)
> > +                       return -EINVAL;
> > +
> > +               ptr = (u64 *)((u8 *)ptr + blksz - sizeof(u64));
> > +
> > +               /* write an 8 bytes pattern at the end of the current block*/
> > +               if (!buffer)
> > +                       *ptr = NVMXIP_BLK_END_PATTERN;
> > +               else if (*ptr != NVMXIP_BLK_END_PATTERN)
> > +                       return -EINVAL;
> 
> You can use ut_assert...() here so that people can see which line failed
> 
> > +       }
> > +
> > +       if (!buffer)
> > +               unmap_sysmem(base);
> > +
> > +       return 0;
> > +}
> > +
> > +static int dm_test_nvmxip(struct unit_test_state *uts)
> > +{
> > +       struct nvmxip_plat *plat_data = NULL;
> > +       struct udevice *dev = NULL, *bdev = NULL;
> > +       u8 device_idx;
> > +       void *buffer = NULL;
> > +       unsigned long flashsz;
> > +
> > +       /* set the flash content first for both devices */
> > +       dm_nvmxip_flash_sanity(0, NULL);
> > +       dm_nvmxip_flash_sanity(1, NULL);
> > +
> > +       /*  probing all NVM XIP QSPI devices */
> > +       for (device_idx = 0, uclass_first_device(UCLASS_NVMXIP, &dev);
> > +            dev;
> > +            uclass_next_device(&dev), device_idx++) {
> > +               plat_data = dev_get_plat(dev);
> > +
> > +               /* device tree entries checks */
> > +               ut_assertok(nvmqspi_refdata[device_idx].phys_base != plat_data->phys_base);
> > +               ut_assertok(nvmqspi_refdata[device_idx].lba_shift != plat_data->lba_shift);
> > +               ut_assertok(nvmqspi_refdata[device_idx].lba != plat_data->lba);
> > +
> > +               /* before reading all the flash blocks, let's calculate the flash size */
> > +               flashsz = plat_data->lba << plat_data->lba_shift;
> > +
> > +               /* allocate the user buffer where to copy the blocks data to */
> > +               buffer = calloc(flashsz, 1);
> > +               ut_assertok(!buffer);
> > +
> > +               /* the block device is the child of the parent device probed with DT*/
> > +               ut_assertok(device_find_first_child(dev, &bdev));
> > +
> > +               /* reading all the flash blocks*/
> > +               ut_asserteq(plat_data->lba, blk_read(bdev, 0, plat_data->lba, buffer));
> > +
> > +               /* compare the data read from flash with the expected data */
> > +               ut_assertok(dm_nvmxip_flash_sanity(device_idx, buffer));
> > +
> > +               free(buffer);
> > +       }
> > +
> > +       ut_assertok(device_idx != SANDBOX_NVMXIP_DEVICES);
> > +
> > +       return CMD_RET_SUCCESS;
> > +}
> > +
> > +DM_TEST(dm_test_nvmxip, UT_TESTF_SCAN_FDT | UT_TESTF_CONSOLE_REC);
> > --
> > 2.17.1
> >
> 
> It seems like you are using the same driver for sandbox as for the
> real hardware. Is that right? There is nothing really wrong with that,
> it's just unusual.

Yes, the driver is exactly the same for real HW and sandbox because the logic is the same. No need to duplicate it.

Cheers,
Abdellatif

  reply	other threads:[~2023-04-17  9:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-16 17:28 [PATCH v1 0/6] introduce NVM XIP block storage emulation abdellatif.elkhlifi
2023-01-16 17:28 ` [PATCH v1 1/6] drivers/nvmxip: " abdellatif.elkhlifi
2023-02-07 18:38   ` Simon Glass
2023-04-17  9:19     ` Abdellatif El Khlifi
2023-01-16 17:28 ` [PATCH v1 2/6] sandbox64: fix: return unsigned long in readq() abdellatif.elkhlifi
2023-01-16 17:28 ` [PATCH v1 3/6] sandbox64: add support for NVMXIP QSPI abdellatif.elkhlifi
2023-02-07  4:02   ` Simon Glass
2023-02-07 16:30     ` Tom Rini
2023-02-07 18:38       ` Simon Glass
2023-04-17  9:25         ` Abdellatif El Khlifi
2023-01-16 17:28 ` [PATCH v1 4/6] corstone1000: add NVM XIP QSPI device tree node abdellatif.elkhlifi
2023-01-16 17:28 ` [PATCH v1 5/6] corstone1000: enable NVM XIP QSPI flash abdellatif.elkhlifi
2023-01-16 17:28 ` [PATCH v1 6/6] sandbox64: add a test case for UCLASS_NVMXIP abdellatif.elkhlifi
2023-02-07  4:02   ` Simon Glass
2023-04-17  9:21     ` Abdellatif El Khlifi [this message]
2023-02-06 14:17 ` [PATCH v1 0/6] introduce NVM XIP block storage emulation Abdellatif El Khlifi
2023-02-07  4:02   ` Simon Glass
2023-04-17  9:11 ` [PATCH v2 0/7] " Abdellatif El Khlifi
2023-04-17  9:11   ` [PATCH v2 1/7] drivers/mtd/nvmxip: " Abdellatif El Khlifi
2023-04-17  9:11   ` [PATCH v2 2/7] drivers/mtd/nvmxip: introduce QSPI XIP driver Abdellatif El Khlifi
2023-04-17  9:11   ` [PATCH v2 3/7] sandbox64: fix: return unsigned long in readq() Abdellatif El Khlifi
2023-04-19  1:49     ` Simon Glass
2023-04-17  9:11   ` [PATCH v2 4/7] sandbox64: add support for NVMXIP QSPI Abdellatif El Khlifi
2023-04-17  9:11   ` [PATCH v2 5/7] corstone1000: add NVM XIP QSPI device tree node Abdellatif El Khlifi
2023-04-17  9:11   ` [PATCH v2 6/7] corstone1000: enable NVM XIP QSPI flash Abdellatif El Khlifi
2023-04-17  9:11   ` [PATCH v2 7/7] sandbox64: add a test case for UCLASS_NVMXIP Abdellatif El Khlifi
2023-04-27 23:23   ` [PATCH v2 0/7] introduce NVM XIP block storage emulation Tom Rini

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=20230417092143.GA42378@e130802.arm.com \
    --to=abdellatif.elkhlifi@arm.com \
    --cc=nd@arm.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /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