From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A6D74C77B70 for ; Mon, 17 Apr 2023 09:22:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 66D6E856FA; Mon, 17 Apr 2023 11:21:54 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 74C4385830; Mon, 17 Apr 2023 11:21:53 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 98FD780B9E for ; Mon, 17 Apr 2023 11:21:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=abdellatif.elkhlifi@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 80FCA1063; Mon, 17 Apr 2023 02:22:34 -0700 (PDT) Received: from e130802.arm.com (unknown [10.57.22.150]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 057F63F6C4; Mon, 17 Apr 2023 02:21:48 -0700 (PDT) Date: Mon, 17 Apr 2023 10:21:43 +0100 From: Abdellatif El Khlifi To: Simon Glass Cc: nd@arm.com, u-boot@lists.denx.de Subject: Re: [PATCH v1 6/6] sandbox64: add a test case for UCLASS_NVMXIP Message-ID: <20230417092143.GA42378@e130802.arm.com> References: <20230116172832.1946-1-abdellatif.elkhlifi@arm.com> <20230116172832.1946-7-abdellatif.elkhlifi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Mon, Feb 06, 2023 at 09:02:40PM -0700, Simon Glass wrote: > Hi, > > On Mon, 16 Jan 2023 at 10:29, wrote: > > > > From: Abdellatif El Khlifi > > > > 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 > > --- > > 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 > > 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 > > > > 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 > > + * > > + * Authors: > > + * Abdellatif El Khlifi > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include "../../drivers/nvmxip/nvmxip.h" > > move to end > > > +#include > > +#include > > + > > +/* 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