Re: [PATCH v2 1/1] efi_loader: prepare for read only OP-TEE variables
On 6/23/20 1:44 AM, AKASHI Takahiro wrote: > On Mon, Jun 22, 2020 at 06:10:27PM +0200, Heinrich Schuchardt wrote: >> We currently have two implementations of UEFI variables: >> >> * variables provided via an OP-TEE module >> * variables stored in the U-Boot environment >> >> Read only variables are up to now only implemented in the U-Boot >> environment implementation. >> >> Provide a common interface for both implementations that allows handling >> read-only variables. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> v2: >> add missing efi_variable.h >> consider attributes==NULL in efi_variable_get() >> --- >> include/efi_variable.h | 40 +++ >> lib/efi_loader/Makefile | 1 + >> lib/efi_loader/efi_variable.c| 171 --- >> lib/efi_loader/efi_variable_common.c | 79 + >> lib/efi_loader/efi_variable_tee.c| 75 >> 5 files changed, 188 insertions(+), 178 deletions(-) >> create mode 100644 include/efi_variable.h >> create mode 100644 lib/efi_loader/efi_variable_common.c >> >> diff --git a/include/efi_variable.h b/include/efi_variable.h >> new file mode 100644 >> index 00..784dbd9cf4 >> --- /dev/null >> +++ b/include/efi_variable.h > > I think that all the stuff here should be put in efi_loader.h. > I don't see any benefit of having a separate header. > > This is more or less a question of taste. My motivation is: * efi_loader.h is rather large (805 lines). * Other variable functions will be added. * The functions defined here are used only in very few places while efi_loader.h is included in 57 files. Best regards Heinrich
RE: [PATCH] cmd: mmc: Add mmc reg read command for reading card registers
Hi Marek,
> Subject: [PATCH] cmd: mmc: Add mmc reg read command for reading card
> registers
This patch breaks ci build.
+u-boot.imx exceeds file size limit:
+ limit: 0x5fc00 bytes
+ actual: 0x60c00 bytes
+ excess: 0x1000 bytes
+make[1]: *** [Makefile:1204: u-boot.imx] Error 1
+make[1]: *** Deleting file 'u-boot.imx'
+make: *** [Makefile:167: sub-make] Error 2
Regards,
Peng.
>
> Add extension to the 'mmc' command to read out the card registers.
> Currently, only the eMMC OCR/CID/CSD/EXTCSD/RCA/DSR register are
> supported. A register value can either be displayed or read into an
> environment variable.
>
> Signed-off-by: Marek Vasut
> ---
> cmd/Kconfig | 8 +
> cmd/mmc.c | 94
> +
> 2 files changed, 102 insertions(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 192b3b262f..a0cf03c911 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1104,6 +1104,14 @@ config CMD_BKOPS_ENABLE
> on a eMMC device. The feature is optionally available on eMMC
> devices
> conforming to standard >= 4.41.
>
> +config CMD_MMC_REG
> + bool "Enable support for reading card registers in the mmc command"
> + depends on CMD_MMC
> + default y
> + help
> + Enable the commands for reading card registers. This is useful
> + mostly for debugging or extracting details from the card.
> +
> config CMD_MMC_RPMB
> bool "Enable support for RPMB in the mmc command"
> depends on SUPPORT_EMMC_RPMB
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 1529a3e05d..55fbfe822e 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -912,6 +912,93 @@ static int do_mmc_bkops_enable(struct cmd_tbl
> *cmdtp, int flag, } #endif
>
> +#if CONFIG_IS_ENABLED(CMD_MMC_REG)
> +static int do_mmc_reg(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> + struct mmc *mmc;
> + int i, ret;
> + u32 off;
> +
> + if (argc < 3 || argc > 5)
> + return CMD_RET_USAGE;
> +
> + mmc = find_mmc_device(curr_device);
> + if (!mmc) {
> + printf("no mmc device at slot %x\n", curr_device);
> + return CMD_RET_FAILURE;
> + }
> +
> + if (IS_SD(mmc)) {
> + printf("SD registers are not supported\n");
> + return CMD_RET_FAILURE;
> + } else {
> + off = simple_strtoul(argv[3], NULL, 10);
> + if (!strcmp(argv[2], "cid")) {
> + if (off > 1)
> + return CMD_RET_USAGE;
> + printf("CID[%i]: 0x%08x\n", off, mmc->cid[off]);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->cid[off]);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "csd")) {
> + if (off > 3)
> + return CMD_RET_USAGE;
> + printf("CSD[%i]: 0x%08x\n", off, mmc->csd[off]);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->csd[off]);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "dsr")) {
> + printf("DSR: 0x%08x\n", mmc->dsr);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->dsr);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "ocr")) {
> + printf("OCR: 0x%08x\n", mmc->ocr);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->ocr);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "rca")) {
> + printf("RCA: 0x%08x\n", mmc->rca);
> + if (argv[4])
> + env_set_hex(argv[4], mmc->rca);
> + return CMD_RET_SUCCESS;
> + }
> + if (!strcmp(argv[2], "extcsd") &&
> + mmc->version >= MMC_VERSION_4_41) {
> + ret = mmc_send_ext_csd(mmc, ext_csd);
> + if (ret)
> + return ret;
> + if (!strcmp(argv[3], "all")) {
> + /* Dump the entire register */
> + printf("EXT_CSD:");
> + for (i = 0; i < MMC_MAX_BLOCK_LEN; i++) {
> + if (!(i % 10))
> + printf("\n%03i: ", i);
> + printf(" %02x", ext_csd[i]);
> + }
> + printf("\n");
> + return CMD_RET_SUCCESS;
> + }
> + off = simple_strtoul(argv[3], NULL, 10);
> +
Re: [PATCH 5/5] configs: reset: fu540: enable dm reset framework for SiFive SoC
On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam wrote: > > Add necessary defconfig and Kconfig entries to enable SiFive SoC's > reset driver so as to utilise U-Boot's reset framework. > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > configs/sifive_fu540_defconfig | 2 ++ > drivers/reset/Kconfig | 9 + > drivers/reset/Makefile | 1 + > 3 files changed, 12 insertions(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: [PATCH 4/5] sifive: reset: add DM based reset driver for SiFive SoC's
On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam wrote: > > PRCI module within SiFive SoC's has register with which we can > reset the sub-systems within the SoC. The resets to DDR and ethernet > sub systems within FU540-C000 SoC are active low, and are hold low > by default on power-up. Currently these are directly asserted within > prci driver via register read/write. > With the DM based reset driver support here, we bind the reset > driver with clock (prci) driver and assert the reset signals of > both sub-system's appropriately. > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > arch/riscv/include/asm/arch-fu540/reset.h | 13 > drivers/clk/sifive/fu540-prci.c | 73 ++ > drivers/reset/reset-sifive.c | 118 > ++ > 3 files changed, 189 insertions(+), 15 deletions(-) > create mode 100644 arch/riscv/include/asm/arch-fu540/reset.h > create mode 100644 drivers/reset/reset-sifive.c > Reviewed-by: Bin Meng Tested-by: Bin Meng
[PATCHv2] usb: max3420: add the gadget driver
From: Jassi Brar
MAX3420 implements FullSpeed USB Device over SPI.
Another version MAX3421, also implements USB Host mode.
This driver should be good for the device mode of max3421 as well.
Signed-off-by: Jassi Brar
---
drivers/usb/gadget/Kconfig| 6 +
drivers/usb/gadget/Makefile | 1 +
drivers/usb/gadget/gadget_chips.h | 8 +
drivers/usb/gadget/max3420_udc.c | 877 ++
4 files changed, 892 insertions(+)
create mode 100644 drivers/usb/gadget/max3420_udc.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 46aa3fe954..7c0df5c264 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -105,6 +105,12 @@ config CI_UDC
Say Y here to enable device controller functionality of the
ChipIdea driver.
+config USB_GADGET_MAX3420
+ bool "MAX3420 USB Over SPI"
+ depends on DM_SPI
+ help
+ MAX3420, from MAXIM, implements USB-over-SPI Full-Speed device
controller.
+
config USB_GADGET_VBUS_DRAW
int "Maximum VBUS Power usage (2-500 mA)"
range 2 500
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 70f3bf43e7..f560068b41 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_USB_GADGET_BCM_UDC_OTG_PHY) += bcm_udc_otg_phy.o
obj-$(CONFIG_USB_GADGET_DWC2_OTG) += dwc2_udc_otg.o
obj-$(CONFIG_USB_GADGET_DWC2_OTG_PHY) += dwc2_udc_otg_phy.o
obj-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
+obj-$(CONFIG_USB_GADGET_MAX3420) += max3420_udc.o
obj-$(CONFIG_CI_UDC) += ci_udc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_USB_GADGET_DOWNLOAD) += g_dnl.o
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index 91b0285244..587204cfb7 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -155,6 +155,12 @@
#define gadget_is_cdns3(g)0
#endif
+#ifdef CONFIG_USB_GADGET_MAX3420
+#define gadget_is_max3420(g)(!strcmp("max3420-udc", (g)->name))
+#else
+#define gadget_is_max3420(g)0
+#endif
+
/**
* usb_gadget_controller_number - support bcdDevice id convention
* @gadget: the controller being driven
@@ -216,5 +222,7 @@ static inline int usb_gadget_controller_number(struct
usb_gadget *gadget)
return 0x23;
else if (gadget_is_cdns3(gadget))
return 0x24;
+ else if (gadget_is_max3420(gadget))
+ return 0x25;
return -ENOENT;
}
diff --git a/drivers/usb/gadget/max3420_udc.c b/drivers/usb/gadget/max3420_udc.c
new file mode 100644
index 00..bde71be7c6
--- /dev/null
+++ b/drivers/usb/gadget/max3420_udc.c
@@ -0,0 +1,877 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX3420_MAX_EPS4
+#define EP_MAX_PACKET 64 /* Same for all Endpoints */
+#define EPNAME_SIZE16 /* Buffer size for endpoint name */
+
+#define ACKSTATBIT(0)
+
+#define MAX3420_SPI_DIR_RD 0 /* read register from MAX3420 */
+#define MAX3420_SPI_DIR_WR 1 /* write register to MAX3420 */
+
+/* SPI commands: */
+#define MAX3420_SPI_DIR_SHIFT 1
+#define MAX3420_SPI_REG_SHIFT 3
+
+#define MAX3420_REG_EP0FIFO0
+#define MAX3420_REG_EP1FIFO1
+#define MAX3420_REG_EP2FIFO2
+#define MAX3420_REG_EP3FIFO3
+#define MAX3420_REG_SUDFIFO4
+#define MAX3420_REG_EP0BC 5
+#define MAX3420_REG_EP1BC 6
+#define MAX3420_REG_EP2BC 7
+#define MAX3420_REG_EP3BC 8
+
+#define MAX3420_REG_EPSTALLS 9
+ #define bACKSTATBIT(6)
+ #define bSTLSTATBIT(5)
+ #define bSTLEP3IN BIT(4)
+ #define bSTLEP2IN BIT(3)
+ #define bSTLEP1OUT BIT(2)
+ #define bSTLEP0OUT BIT(1)
+ #define bSTLEP0IN BIT(0)
+
+#define MAX3420_REG_CLRTOGS10
+ #define bEP3DISAB BIT(7)
+ #define bEP2DISAB BIT(6)
+ #define bEP1DISAB BIT(5)
+ #define bCTGEP3IN BIT(4)
+ #define bCTGEP2IN BIT(3)
+ #define bCTGEP1OUT BIT(2)
+
+#define MAX3420_REG_EPIRQ 11
+#define MAX3420_REG_EPIEN 12
+ #define bSUDAVIRQ BIT(5)
+ #define bIN3BAVIRQ BIT(4)
+ #define bIN2BAVIRQ BIT(3)
+ #define bOUT1DAVIRQ BIT(2)
+ #define bOUT0DAVIRQ BIT(1)
+ #define bIN0BAVIRQ BIT(0)
+
+#define MAX3420_REG_USBIRQ 13
+#define MAX3420_REG_USBIEN 14
+ #define bOSCOKIRQ BIT(0)
+ #define bRWUDNIRQ BIT(1)
+ #define bBUSACTIRQ BIT(2)
+ #define bURESIRQBIT(3)
+ #define bSUSPIRQBIT(4)
+ #define bNOVBUSIRQ BIT(5)
+ #define bVBUSIRQBIT(6)
+ #define bURESDNIRQ BIT(7)
+
+#define MAX3420_REG_USBCTL 15
+ #define bHOSCSTEN BIT(7)
Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
Hi Rick, On Wed, Jun 24, 2020 at 1:24 PM Pragnesh Patel wrote: > > Hi Rick, > > >-Original Message- > >From: Rick Chen > >Sent: 24 June 2020 10:44 > >To: Pragnesh Patel > >Cc: U-Boot Mailing List ; Atish Patra > >; palmerdabb...@google.com; Bin Meng > >; Paul Walmsley ( Sifive) > >; Anup Patel ; Sagar > >Kadam ; Palmer Dabbelt ; > >Jagan Teki ; rick ; Alan > >Kao > >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > > > >[External Email] Do not click links or attachments unless you recognize the > >sender and know the content is safe > > > >Hi Pragnesh > > > >> Hi Rick, > >> > >> >-Original Message- > >> >From: Rick Chen > >> >Sent: 24 June 2020 06:30 > >> >To: Pragnesh Patel > >> >Cc: U-Boot Mailing List ; Atish Patra > >> >; palmerdabb...@google.com; Bin Meng > >> >; Paul Walmsley ( Sifive) > >> >; Anup Patel ; Sagar > >> >Kadam ; Palmer Dabbelt > >; > >> >Jagan Teki ; rick ; > >> >Alan Kao > >> >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM > >> >driver > >> > > >> >[External Email] Do not click links or attachments unless you > >> >recognize the sender and know the content is safe > >> > > >> >Hi Pragnesh > >> > > >> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > >> >> Sent: Friday, May 29, 2020 2:45 PM > >> >> To: u-boot@lists.denx.de > >> >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; > >> >bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com; > >> >sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; > >> >Palmer Dabbelt > >> >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > >> >> > >> >> This patch enables SiFive PWM driver for the SiFive Unleashed board. > >> >> > >> >> Signed-off-by: Pragnesh Patel > >> >> --- > >> >> board/sifive/fu540/Kconfig | 2 ++ > >> >> 1 file changed, 2 insertions(+) > >> >> > >> >> diff --git a/board/sifive/fu540/Kconfig > >> >> b/board/sifive/fu540/Kconfig index > >> >86193d7668..683668d059 100644 > >> >> --- a/board/sifive/fu540/Kconfig > >> >> +++ b/board/sifive/fu540/Kconfig > >> >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy > >> >> imply SMP > >> >> imply MISC > >> >> imply SIFIVE_OTP > >> >> + imply DM_PWM > >> >> + imply PWM_SIFIVE > >> >> > >> > > >> >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive. > >> >It is weird to introduce here and not appropriate to depend on another > >patch. > >> > >> Do you want me to send this 2 patches separately independent of each > >other ? > > > >How about merged [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > >into [PATCH v2 0/2] Add support for PWM SiFive ? > > I am okay with it, you can go ahead and merge this patch into PWM series of > Yash. > They are separate patches and should keep separate. I am not sure what's the issue we want to resolve? Regards, Bin
RE: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
Hi Rick, >-Original Message- >From: Rick Chen >Sent: 24 June 2020 10:44 >To: Pragnesh Patel >Cc: U-Boot Mailing List ; Atish Patra >; palmerdabb...@google.com; Bin Meng >; Paul Walmsley ( Sifive) >; Anup Patel ; Sagar >Kadam ; Palmer Dabbelt ; >Jagan Teki ; rick ; Alan >Kao >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > >[External Email] Do not click links or attachments unless you recognize the >sender and know the content is safe > >Hi Pragnesh > >> Hi Rick, >> >> >-Original Message- >> >From: Rick Chen >> >Sent: 24 June 2020 06:30 >> >To: Pragnesh Patel >> >Cc: U-Boot Mailing List ; Atish Patra >> >; palmerdabb...@google.com; Bin Meng >> >; Paul Walmsley ( Sifive) >> >; Anup Patel ; Sagar >> >Kadam ; Palmer Dabbelt >; >> >Jagan Teki ; rick ; >> >Alan Kao >> >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM >> >driver >> > >> >[External Email] Do not click links or attachments unless you >> >recognize the sender and know the content is safe >> > >> >Hi Pragnesh >> > >> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] >> >> Sent: Friday, May 29, 2020 2:45 PM >> >> To: u-boot@lists.denx.de >> >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; >> >bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com; >> >sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; >> >Palmer Dabbelt >> >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver >> >> >> >> This patch enables SiFive PWM driver for the SiFive Unleashed board. >> >> >> >> Signed-off-by: Pragnesh Patel >> >> --- >> >> board/sifive/fu540/Kconfig | 2 ++ >> >> 1 file changed, 2 insertions(+) >> >> >> >> diff --git a/board/sifive/fu540/Kconfig >> >> b/board/sifive/fu540/Kconfig index >> >86193d7668..683668d059 100644 >> >> --- a/board/sifive/fu540/Kconfig >> >> +++ b/board/sifive/fu540/Kconfig >> >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy >> >> imply SMP >> >> imply MISC >> >> imply SIFIVE_OTP >> >> + imply DM_PWM >> >> + imply PWM_SIFIVE >> >> >> > >> >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive. >> >It is weird to introduce here and not appropriate to depend on another >patch. >> >> Do you want me to send this 2 patches separately independent of each >other ? > >How about merged [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver >into [PATCH v2 0/2] Add support for PWM SiFive ? I am okay with it, you can go ahead and merge this patch into PWM series of Yash. > >Thanks, >Rick > >> >> > >> >Thanks, >> >Rick >> > >> >> endif >> >> -- >> >> 2.17.1
Re: [PATCH 4/5] sifive: reset: add DM based reset driver for SiFive SoC's
On 6/24/20 1:15 AM, Bin Meng wrote:
> Hi Sean,
>
> On Wed, Jun 24, 2020 at 1:04 PM Sean Anderson wrote:
>>
>> On 6/24/20 1:01 AM, Bin Meng wrote:
>>> Hi Sean,
>>>
>>> On Wed, Jun 24, 2020 at 12:17 PM Sean Anderson wrote:
On 6/22/20 8:27 AM, Sagar Shrikant Kadam wrote:
> The resets to DDR and ethernet sub-system are connected to
> PRCI device reset control register, these reset signals
> are active low and are held low at power-up. Add these reset
> producer and consumer details needed by the reset driver.
>
> Signed-off-by: Sagar Shrikant Kadam
> Reviewed-by: Pragnesh Patel
> ---
> arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> index 9bba554..b37241e 100644
> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> @@ -59,6 +59,16 @@
> reg = <0x0 0x200 0x0 0xc>;
> u-boot,dm-spl;
> };
> + prci: clock-controller@1000 {
Shouldn't this have a compatible property?
>>>
>>> This is the U-Boot specific dts fragment. See fu540-c000.dtsi
>>
>> I ask because this node sits in /soc, and all the other nodes in /soc
>> have compatible strings. Since this device is bound by the clock driver,
>> perhaps it should be located under /soc/prci instead.
>
> fu540-c000.dtsi has everything you asked.
>
Ah, I didn't see that this was an extension. Looks good to me.
--Sean
Re: [PATCH 4/5] sifive: reset: add DM based reset driver for SiFive SoC's
Hi Sean,
On Wed, Jun 24, 2020 at 1:04 PM Sean Anderson wrote:
>
> On 6/24/20 1:01 AM, Bin Meng wrote:
> > Hi Sean,
> >
> > On Wed, Jun 24, 2020 at 12:17 PM Sean Anderson wrote:
> >>
> >> On 6/22/20 8:27 AM, Sagar Shrikant Kadam wrote:
> >>> The resets to DDR and ethernet sub-system are connected to
> >>> PRCI device reset control register, these reset signals
> >>> are active low and are held low at power-up. Add these reset
> >>> producer and consumer details needed by the reset driver.
> >>>
> >>> Signed-off-by: Sagar Shrikant Kadam
> >>> Reviewed-by: Pragnesh Patel
> >>> ---
> >>> arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> index 9bba554..b37241e 100644
> >>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> >>> @@ -59,6 +59,16 @@
> >>> reg = <0x0 0x200 0x0 0xc>;
> >>> u-boot,dm-spl;
> >>> };
> >>> + prci: clock-controller@1000 {
> >>
> >> Shouldn't this have a compatible property?
> >
> > This is the U-Boot specific dts fragment. See fu540-c000.dtsi
>
> I ask because this node sits in /soc, and all the other nodes in /soc
> have compatible strings. Since this device is bound by the clock driver,
> perhaps it should be located under /soc/prci instead.
fu540-c000.dtsi has everything you asked.
Regards,
Bin
Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
Hi Pragnesh > Hi Rick, > > >-Original Message- > >From: Rick Chen > >Sent: 24 June 2020 06:30 > >To: Pragnesh Patel > >Cc: U-Boot Mailing List ; Atish Patra > >; palmerdabb...@google.com; Bin Meng > >; Paul Walmsley ( Sifive) > >; Anup Patel ; Sagar > >Kadam ; Palmer Dabbelt ; > >Jagan Teki ; rick ; Alan > >Kao > >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > > > >[External Email] Do not click links or attachments unless you recognize the > >sender and know the content is safe > > > >Hi Pragnesh > > > >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > >> Sent: Friday, May 29, 2020 2:45 PM > >> To: u-boot@lists.denx.de > >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; > >bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com; > >sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; Palmer > >Dabbelt > >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > >> > >> This patch enables SiFive PWM driver for the SiFive Unleashed board. > >> > >> Signed-off-by: Pragnesh Patel > >> --- > >> board/sifive/fu540/Kconfig | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index > >86193d7668..683668d059 100644 > >> --- a/board/sifive/fu540/Kconfig > >> +++ b/board/sifive/fu540/Kconfig > >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy > >> imply SMP > >> imply MISC > >> imply SIFIVE_OTP > >> + imply DM_PWM > >> + imply PWM_SIFIVE > >> > > > >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive. > >It is weird to introduce here and not appropriate to depend on another patch. > > Do you want me to send this 2 patches separately independent of each other ? How about merged [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver into [PATCH v2 0/2] Add support for PWM SiFive ? Thanks, Rick > > > > >Thanks, > >Rick > > > >> endif > >> -- > >> 2.17.1
Re: [RESEND PATCH] usb: max3420: add the gadget driver
On Tue, Jun 16, 2020 at 2:29 AM Lukasz Majewski wrote:
>
> Hi Jassi,
>
> > ... a polite ping, Lukasz.
>
> The only excuse for so long lack of my response are my personal issues
> caused by the covid-19.
>
Sorry if I came across as pestering you. I hope all is well now.
.
> > > +
> > > +#define MAX3420_REG_IOPINS 20
> > > +#define MAX3420_REG_IOPINS221
> > > +#define MAX3420_REG_GPINIRQ22
> > > +#define MAX3420_REG_GPINIEN23
> > > +#define MAX3420_REG_GPINPOL24
> > > +#define MAX3420_REG_HIRQ 25
> > > +#define MAX3420_REG_HIEN 26
> > > +#define MAX3420_REG_MODE 27
> > > +#define MAX3420_REG_PERADDR28
> > > +#define MAX3420_REG_HCTL 29
> > > +#define MAX3420_REG_HXFR 30
> > > +#define MAX3420_REG_HRSL 31
> > > +
>
> When I do look into drivers/usb/gadget/f_dfu.* the defines are placed
> in the f_dfu.h file.
>
One school of thought is to contain all code in one file, especially
when no other file should access it -- these defines are very max3420
specific and none else should need these.
But I am fine if you want them in a separate file.
> > > +#define field(val, bit)((val) << (bit))
> > > +
> > > +#define msleep(a) udelay((a) * 1000)
> > > +
>
> Aren't those two above already defined in some *.h files?
>
I replaced msleep with mdelay as Marek suggested.
I couldn't find the simple shift op define as field.
> > > +
> > > +static void spi_wr8_ack(struct max3420_udc *udc, u8 reg, u8 val,
> > > int actstat) +{
> > > + struct spi_slave *slave = udc->slave;
> > > + u8 txdata[2];
> > > +
> > > + txdata[0] = field(reg, MAX3420_SPI_REG_SHIFT) |
> > > + field(MAX3420_SPI_DIR_WR,
> > > MAX3420_SPI_DIR_SHIFT) |
> > > + (actstat ? ACKSTAT : 0);
> > > + txdata[1] = val;
> > > +
> > > + spi_xfer(slave, 2 * 8, txdata, NULL, SPI_XFER_ONCE);
> > > +}
>
> 2 * 8 -> sizeof(txdata) ?
>
Sure.
> > > +
> > > +static void spi_wr8(struct max3420_udc *udc, u8 reg, u8 val)
> > > +{
> > > + spi_wr8_ack(udc, reg, val, 0);
> > > +}
> > > +
> > > +static void spi_rd_buf(struct max3420_udc *udc, u8 reg, void *buf,
> > > u8 len) +{
> > > + struct spi_slave *slave = udc->slave;
> > > + u8 txdata[1];
> > > +
> > > + txdata[0] = (field(reg, MAX3420_SPI_REG_SHIFT) |
> > > +field(MAX3420_SPI_DIR_RD,
> > > MAX3420_SPI_DIR_SHIFT)); +
> > > + spi_xfer(slave, 1 * 8, txdata, NULL, SPI_XFER_BEGIN);
>
> I think that 1 * 8 shall be replaced with just 8.
>
sizeof(txdata) is more consistent
> > > +
> > > +static int max3420_udc_start(struct usb_gadget *gadget,
> > > +struct usb_gadget_driver *driver)
> > > +{
> > > + struct max3420_udc *udc = to_udc(gadget);
> > > + unsigned long flags;
> > > +
> > > + udc->driver = driver;
> > > + udc->remote_wkp = 0;
> > > + udc->softconnect = true;
> > > +
> > > + //if (udc->vbus_active)
> > > + __max3420_start(udc);
> > > +
>
> Please refactor the code and remove any lines started with //.
>
ok.
> > > +static int max3420_wakeup(struct usb_gadget *gadget)
> > > +{
> > > + struct max3420_udc *udc = to_udc(gadget);
> > > + u8 usbctl;
> > > +
> > > + /* Only if wakeup allowed by host */
> > > + if (!udc->remote_wkp || !udc->suspended)
> > > + return 0;
> > > +
> > > + /* Set Remote-WkUp Signal*/
>
> WkUp? -> Wakeup?
>
Ok.
> > > +
> > > +static int max3420_irq(struct max3420_udc *udc)
> > > +{
> > > + /* needed ? */
>
> Please make sure if the code is needed or not.
>
Yup.
> > > +static void max3420_setup_spi(struct max3420_udc *udc)
> > > +{
> > > + u8 reg[8];
> > > +
> > > + spi_claim_bus(udc->slave);
> > > + /* necessary? */
>
> The same as above. If there are any quirks or doubts - please state
> them in the verbose comment.
>
The spec doesn't say explicitly but my platform needed these. So I'll
keep them until someone comes with a reason not to.
> > > +
> > > +static int max3420_udc_probe(struct udevice *dev)
> > > +{
> > > + struct max3420_udc *udc = dev_get_priv(dev);
> > > + struct udevice *spid;
> > > +
> > > + spi_get_bus_and_cs(3, 0, 1000, SPI_MODE_3,
> > > "spi_generic_drv",
> > > + NULL, , >slave);
>
> IMHO the bus number (3?), CS (0), speed (1000) and mode
> (SPI_MODE_3) shall be read from device tree.
>
> Some other setups, which would use this IC, could reuse the code when
> it is connected to other bus/CS/mode/speed.
>
Yes, of course.
>
> A few more remarks:
>
> 1. Is this code ported from the Linux kernel? If yes, please explicitly
> state SHA1 and version from which it was ported.
>
This code has no roots in the kernel.
> 2. Does this particular driver require any extra explanation or
> description, which shall be put into ./doc/?
>
We don't implement any platform specific feature, so it is generic
Re: [PATCH 4/5] sifive: reset: add DM based reset driver for SiFive SoC's
On 6/24/20 1:01 AM, Bin Meng wrote:
> Hi Sean,
>
> On Wed, Jun 24, 2020 at 12:17 PM Sean Anderson wrote:
>>
>> On 6/22/20 8:27 AM, Sagar Shrikant Kadam wrote:
>>> The resets to DDR and ethernet sub-system are connected to
>>> PRCI device reset control register, these reset signals
>>> are active low and are held low at power-up. Add these reset
>>> producer and consumer details needed by the reset driver.
>>>
>>> Signed-off-by: Sagar Shrikant Kadam
>>> Reviewed-by: Pragnesh Patel
>>> ---
>>> arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> index 9bba554..b37241e 100644
>>> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
>>> @@ -59,6 +59,16 @@
>>> reg = <0x0 0x200 0x0 0xc>;
>>> u-boot,dm-spl;
>>> };
>>> + prci: clock-controller@1000 {
>>
>> Shouldn't this have a compatible property?
>
> This is the U-Boot specific dts fragment. See fu540-c000.dtsi
I ask because this node sits in /soc, and all the other nodes in /soc
have compatible strings. Since this device is bound by the clock driver,
perhaps it should be located under /soc/prci instead.
--Sean
>
>>
>>> + #reset-cells = <1>;
>>> + resets = < PRCI_RST_DDR_CTRL_N>,
>>> + < PRCI_RST_DDR_AXI_N>,
>>> + < PRCI_RST_DDR_AHB_N>,
>>> + < PRCI_RST_DDR_PHY_N>,
>>> + < PRCI_RST_GEMGXL_N>;
>>> + reset-names = "ddr_ctrl", "ddr_axi", "ddr_ahb",
>>> + "ddr_phy", "gemgxl_reset";
>>> + };
>>> dmc: dmc@100b {
>>> compatible = "sifive,fu540-c000-ddr";
>>> reg = <0x0 0x100b 0x0 0x0800
>
> Regards,
> Bin
>
Re: [PATCH 3/5] fu540: dtsi: add reset producer and consumer entries
Hi Sean,
On Wed, Jun 24, 2020 at 12:17 PM Sean Anderson wrote:
>
> On 6/22/20 8:27 AM, Sagar Shrikant Kadam wrote:
> > The resets to DDR and ethernet sub-system are connected to
> > PRCI device reset control register, these reset signals
> > are active low and are held low at power-up. Add these reset
> > producer and consumer details needed by the reset driver.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Reviewed-by: Pragnesh Patel
> > ---
> > arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > index 9bba554..b37241e 100644
> > --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> > @@ -59,6 +59,16 @@
> > reg = <0x0 0x200 0x0 0xc>;
> > u-boot,dm-spl;
> > };
> > + prci: clock-controller@1000 {
>
> Shouldn't this have a compatible property?
This is the U-Boot specific dts fragment. See fu540-c000.dtsi
>
> > + #reset-cells = <1>;
> > + resets = < PRCI_RST_DDR_CTRL_N>,
> > + < PRCI_RST_DDR_AXI_N>,
> > + < PRCI_RST_DDR_AHB_N>,
> > + < PRCI_RST_DDR_PHY_N>,
> > + < PRCI_RST_GEMGXL_N>;
> > + reset-names = "ddr_ctrl", "ddr_axi", "ddr_ahb",
> > + "ddr_phy", "gemgxl_reset";
> > + };
> > dmc: dmc@100b {
> > compatible = "sifive,fu540-c000-ddr";
> > reg = <0x0 0x100b 0x0 0x0800
Regards,
Bin
Re: [RESEND PATCH] usb: max3420: add the gadget driver
Hi Marek,
On Mon, Jun 15, 2020 at 6:49 PM Marek Vasut wrote:
> >> +#define MAX3420_REG_MODE 27
> >> +#define MAX3420_REG_PERADDR28
> >> +#define MAX3420_REG_HCTL 29
> >> +#define MAX3420_REG_HXFR 30
> >> +#define MAX3420_REG_HRSL 31
> >> +
> >> +#define field(val, bit)((val) << (bit))
>
> Is this GENMASK() ?
>
The 'val' is not a mask, otherwise we could use genmask.
> >> +#define msleep(a) udelay((a) * 1000)
>
> Please use mdelay() .
>
Ok.
> >> +static int max3420_udc_start(struct usb_gadget *gadget,
> >> +struct usb_gadget_driver *driver)
> >> +{
> >> + struct max3420_udc *udc = to_udc(gadget);
> >> + unsigned long flags;
> >> +
> >> + udc->driver = driver;
> >> + udc->remote_wkp = 0;
> >> + udc->softconnect = true;
> >> +
> >> + //if (udc->vbus_active)
>
> Is this intended to be commented out ?
>
Yes.
Thank you!
RE: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
Hi Rick, >-Original Message- >From: Rick Chen >Sent: 24 June 2020 06:30 >To: Pragnesh Patel >Cc: U-Boot Mailing List ; Atish Patra >; palmerdabb...@google.com; Bin Meng >; Paul Walmsley ( Sifive) >; Anup Patel ; Sagar >Kadam ; Palmer Dabbelt ; >Jagan Teki ; rick ; Alan >Kao >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > >[External Email] Do not click links or attachments unless you recognize the >sender and know the content is safe > >Hi Pragnesh > >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] >> Sent: Friday, May 29, 2020 2:45 PM >> To: u-boot@lists.denx.de >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; >bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com; >sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; Palmer >Dabbelt >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver >> >> This patch enables SiFive PWM driver for the SiFive Unleashed board. >> >> Signed-off-by: Pragnesh Patel >> --- >> board/sifive/fu540/Kconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index >86193d7668..683668d059 100644 >> --- a/board/sifive/fu540/Kconfig >> +++ b/board/sifive/fu540/Kconfig >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy >> imply SMP >> imply MISC >> imply SIFIVE_OTP >> + imply DM_PWM >> + imply PWM_SIFIVE >> > >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive. >It is weird to introduce here and not appropriate to depend on another patch. Do you want me to send this 2 patches separately independent of each other ? > >Thanks, >Rick > >> endif >> -- >> 2.17.1
Re: [PATCH 3/5] fu540: dtsi: add reset producer and consumer entries
On 6/22/20 8:27 AM, Sagar Shrikant Kadam wrote:
> The resets to DDR and ethernet sub-system are connected to
> PRCI device reset control register, these reset signals
> are active low and are held low at power-up. Add these reset
> producer and consumer details needed by the reset driver.
>
> Signed-off-by: Sagar Shrikant Kadam
> Reviewed-by: Pragnesh Patel
> ---
> arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> index 9bba554..b37241e 100644
> --- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
> @@ -59,6 +59,16 @@
> reg = <0x0 0x200 0x0 0xc>;
> u-boot,dm-spl;
> };
> + prci: clock-controller@1000 {
Shouldn't this have a compatible property?
> + #reset-cells = <1>;
> + resets = < PRCI_RST_DDR_CTRL_N>,
> + < PRCI_RST_DDR_AXI_N>,
> + < PRCI_RST_DDR_AHB_N>,
> + < PRCI_RST_DDR_PHY_N>,
> + < PRCI_RST_GEMGXL_N>;
> + reset-names = "ddr_ctrl", "ddr_axi", "ddr_ahb",
> + "ddr_phy", "gemgxl_reset";
> + };
> dmc: dmc@100b {
> compatible = "sifive,fu540-c000-ddr";
> reg = <0x0 0x100b 0x0 0x0800
>
--Sean
Re: [U-Boot] Pull request: u-boot-riscv/master
On 5/26/20 3:41 AM, Rick Chen wrote: > Hi Tom > >> From: Tom Rini [mailto:tr...@konsulko.com] >> Sent: Monday, May 25, 2020 11:40 PM >> To: Open Source Project uboot >> Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) >> Subject: Re: [U-Boot] Pull request: u-boot-riscv/master >> >> On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote: >> >>> Hi Tom, >>> >>> Please pull some riscv updates: >>> >>> - Add Sipeed Maix support. >>> - sifive: fix palmer's email address. >>> - Move all SMP related SBI calls to SBI_v01. >>> >>> https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926 >>> >>> Thanks >>> Rick >>> >>> >>> The following changes since commit 9c5fef577494769e3ff07952a85f9b7125ef765b: >>> >>> Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400) >>> >>> are available in the Git repository at: >>> >>> g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git >>> >>> for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607: >>> >>> riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800) >>> >> Hi, I just saw this thread, and I would like to comment on a few things. >> There's too many generic changes in this PR for this late in the cycle, for >> things I gather related to the Maix platform. All of the clk and DM changes >> impact virtually all platforms. Please re-do this PR to drop the Maix >> platform support for now, and resubmit that for -next, which I will be >> opening shortly. Everything else however is good for master. > > Thanks for your explanations. > Actually I have the same concern with you before sending this PR. > > I have tried to ask Sean don't mix all codes together in one patchset. > He shall separate and send them individually, If they are not highly > dependent. I have been asked by Bin Meng and others to keep together related patches so that the patch which uses changed/new behaviour is in the same series as the patch which changes the behavior. I have tried to split out unrelated patches and minimize changes. Would you rather all patches which do not explicitly add maix support be split off from this series? > > Following are my suggestions from those patch-work: > > Re: [PATCH v2 01/11] clk: Always use the supplied struct clk > https://patchwork.ozlabs.org/project/uboot/patch/da401261-b73f-afae-0702-ada1e7dd8...@gmail.com/ The composite clock framework is only used by IMX in U-Boot as far as I can tell. As such, it has a number of (mis)features which make it unsuitable for generic code. These quirks are generally worked around in a variety of ways by IMX code, often by using custom functions instead of those within the CCF itself. The maix platform has around 40 clocks in a complicated tree, and is not constrained by RAM or flash. Given these circumstances, I think using the CCF is the correct choice. However, in order to do so, I have had to address many of the quirks. I could also add support for maix by effectively duplicating the CCF within the maix driver. However, I think such a duplication of code is likely to rot over time. I have tried to describe why I think each of the clk patches should be included in their commit messages. It may be unclear what the impact will be on other users of the clock subsystem and the CCF. [01/21] clk: Always use the supplied struct clk This patch only affects users of the CCF. As discussed in the above link, this specific behaviour is left over from when the CCF was ported from Linux, due to the different semantics between struct clk and struct clk_core. The problem here is that with the current system, either a struct device must be associated with each CCF clock (a significant overhead), or custom functions must be used for CCF clock operations. The latter approach is used by the IMX code, but I would like to be able to use the generic functions which are provided by CCF clocks. [v13,02/21] clk: Check that ops of composite clock components exist before calling This only affects the CCF subsystem. This is a bugfix for drivers which use composite clocks and do not always have the same sub-clocks. Without this patch, if one registers a composite clock with a gate sub-clock, and then registers another composite clock without a gate sub-clock, calling a enable or disable on the latter clock will result in calling a NULL pointer. No drivers currently use this functionality, but it is a "gotcha" if one implements a driver which does. [v13,03/21] clk: Unconditionally recursively en-/dis-able clocks This affects all clock drivers, but primarily affects CCF clocks. This patch is designed to handle a case with a configuration like A / \ B C | D where B is a clock with an id of 0. If D is enabled, B and A will not be enabled. If C is enabled, A will also be enabled. If C is then disabled, A will also be disabled. This can cause strange behaviour. I have since added ids to all clocks I use, so this patch can be split off. [v13,04/21] clk: Fix clk_get_by_*
Re: [U-Boot] Pull request: u-boot-riscv/master
Hi Tom > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Wednesday, June 24, 2020 10:58 AM > To: Open Source Project uboot > Cc: Tom Rini; U-Boot Mailing List; Rick Jian-Zhi Chen(陳建志) > Subject: Re: [U-Boot] Pull request: u-boot-riscv/master > > Hi Rick, > > On Wed, Jun 24, 2020 at 10:41 AM wrote: > > > > Hi Tom, > > > > Please pull some riscv updates: > > > > - fu540: dts: Correct reg size of otp and dmc nodes > > - sbi: Add newline to error message > > - sifive/fu540: Enable SPI-NOR support > > > > Thanks > > Rick > > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/701223929 > > > > > > The following changes since commit 4ff63383e3497389e66cf70943a83bdb1810462a: > > > > Merge tag 'u-boot-imx-20200623' of > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-23 08:20:55 > > -0400) > > > > are available in the Git repository at: > > > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > > > for you to fetch changes up to 2148d9c76ef5efbf5b98ca3d3fcbaad465115e70: > > > > riscv: fu540: dts: Correct reg size of otp and dmc nodes (2020-06-24 > > 09:59:30 +0800) > > > > > > Bin Meng (2): > > riscv: fu540: dts: Remove the unnecessary space in the cpu2_intc node > > riscv: fu540: dts: Correct reg size of otp and dmc nodes > > > > Jagan Teki (6): > > sifive: fu540: Add runtime boot mode detection > > sifive: fu540: Add Booting from SPI > > env: Enable SPI flash env for SiFive FU540 > > sifive: fu540: Mark the default env as SPI flash > > sifive: fu540: Add boot flash script offset, size > > sifive: fu540: Enable SF distro bootcmd > > You missed my review comments for Jagan's series. > https://lists.denx.de/pipermail/u-boot/2020-June/417066.html > > Please hold on. Please drop this PR. Thanks, Rick > > > > > Sean Anderson (1): > > riscv: sbi: Add newline to error message > > > > Regards, > Bin > CONFIDENTIALITY NOTICE: > > This e-mail (and its attachments) may contain confidential and legally > privileged information or information protected from disclosure. If you are > not the intended recipient, you are hereby notified that any disclosure, > copying, distribution, or use of the information contained herein is strictly > prohibited. In this case, please immediately notify the sender by return > e-mail, delete the message (and any accompanying documents) and destroy all > printed hard copies. Thank you for your cooperation. > > Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.
Re: [PATCH 3/5] fu540: dtsi: add reset producer and consumer entries
On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam wrote: > > The resets to DDR and ethernet sub-system are connected to > PRCI device reset control register, these reset signals > are active low and are held low at power-up. Add these reset > producer and consumer details needed by the reset driver. > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++ > 1 file changed, 10 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH 2/5] fu540: prci: use common reset indexes defined in binding header
On Wed, Jun 24, 2020 at 11:01 AM Bin Meng wrote: > > On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam > wrote: > > > > Indexes of reset signals available in PRCI driver are also > > defined in include/dt-bindings/clock/sifive-fu540-prci.h. > > So use those instead of defining new ones again within the > > fu540-prci driver. > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel [A Forget to mention, please fix the [A in the next version > > --- > > drivers/clk/sifive/fu540-prci.c | 16 ++-- > > 1 file changed, 6 insertions(+), 10 deletions(-) > > > > Reviewed-by: Bin Meng
Re: [PATCH 2/5] fu540: prci: use common reset indexes defined in binding header
On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam wrote: > > Indexes of reset signals available in PRCI driver are also > defined in include/dt-bindings/clock/sifive-fu540-prci.h. > So use those instead of defining new ones again within the > fu540-prci driver. > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel [A > --- > drivers/clk/sifive/fu540-prci.c | 16 ++-- > 1 file changed, 6 insertions(+), 10 deletions(-) > Reviewed-by: Bin Meng
Re: [U-Boot] Pull request: u-boot-riscv/master
Hi Rick, On Wed, Jun 24, 2020 at 10:41 AM wrote: > > Hi Tom, > > Please pull some riscv updates: > > - fu540: dts: Correct reg size of otp and dmc nodes > - sbi: Add newline to error message > - sifive/fu540: Enable SPI-NOR support > > Thanks > Rick > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/701223929 > > > The following changes since commit 4ff63383e3497389e66cf70943a83bdb1810462a: > > Merge tag 'u-boot-imx-20200623' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-23 08:20:55 > -0400) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 2148d9c76ef5efbf5b98ca3d3fcbaad465115e70: > > riscv: fu540: dts: Correct reg size of otp and dmc nodes (2020-06-24 > 09:59:30 +0800) > > > Bin Meng (2): > riscv: fu540: dts: Remove the unnecessary space in the cpu2_intc node > riscv: fu540: dts: Correct reg size of otp and dmc nodes > > Jagan Teki (6): > sifive: fu540: Add runtime boot mode detection > sifive: fu540: Add Booting from SPI > env: Enable SPI flash env for SiFive FU540 > sifive: fu540: Mark the default env as SPI flash > sifive: fu540: Add boot flash script offset, size > sifive: fu540: Enable SF distro bootcmd You missed my review comments for Jagan's series. https://lists.denx.de/pipermail/u-boot/2020-June/417066.html Please hold on. > > Sean Anderson (1): > riscv: sbi: Add newline to error message > Regards, Bin
[U-Boot] Pull request: u-boot-riscv/master
Hi Tom, Please pull some riscv updates: - fu540: dts: Correct reg size of otp and dmc nodes - sbi: Add newline to error message - sifive/fu540: Enable SPI-NOR support Thanks Rick https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/701223929 The following changes since commit 4ff63383e3497389e66cf70943a83bdb1810462a: Merge tag 'u-boot-imx-20200623' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-23 08:20:55 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git for you to fetch changes up to 2148d9c76ef5efbf5b98ca3d3fcbaad465115e70: riscv: fu540: dts: Correct reg size of otp and dmc nodes (2020-06-24 09:59:30 +0800) Bin Meng (2): riscv: fu540: dts: Remove the unnecessary space in the cpu2_intc node riscv: fu540: dts: Correct reg size of otp and dmc nodes Jagan Teki (6): sifive: fu540: Add runtime boot mode detection sifive: fu540: Add Booting from SPI env: Enable SPI flash env for SiFive FU540 sifive: fu540: Mark the default env as SPI flash sifive: fu540: Add boot flash script offset, size sifive: fu540: Enable SF distro bootcmd Sean Anderson (1): riscv: sbi: Add newline to error message arch/riscv/cpu/fu540/Kconfig| 15 +++ arch/riscv/dts/fu540-c000-u-boot.dtsi | 6 +++--- arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 12 board/sifive/fu540/Kconfig | 1 + board/sifive/fu540/fu540.c | 25 +++-- common/spl/spl_opensbi.c| 2 +- configs/sifive_fu540_defconfig | 4 doc/board/sifive/fu540.rst | 41 + include/configs/sifive-fu540.h | 7 ++- 9 files changed, 102 insertions(+), 11 deletions(-)
Re: [PATCH 1/3] riscv: Do not return error if reserved node already exists
On Tue, Jun 23, 2020 at 5:51 PM Bin Meng wrote:
>
> Hi Atish,
>
> On Wed, Jun 24, 2020 at 2:17 AM Atish Patra wrote:
> >
> > On Tue, Jun 23, 2020 at 12:24 AM Bin Meng wrote:
> > >
> > > Hi Atish,
> > >
> > > On Fri, Jun 19, 2020 at 9:52 AM Atish Patra wrote:
> > > >
> > > > Not all errors are fatal. If a reserved memory node already exists in
> > > > the
> > > > destination device tree, we can continue to boot without failing.
> > > >
> > > > Signed-off-by: Atish Patra
> > > > ---
> > > > arch/riscv/lib/fdt_fixup.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> > > > index 6db48ad04a56..91524d9a5ae9 100644
> > > > --- a/arch/riscv/lib/fdt_fixup.c
> > > > +++ b/arch/riscv/lib/fdt_fixup.c
> > > > @@ -62,7 +62,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src,
> > > > void *dst)
> > > > pmp_mem.end = addr + size - 1;
> > > > err = fdtdec_add_reserved_memory(dst, basename,
> > > > _mem,
> > > > );
> > > > - if (err < 0) {
> > > > + if (err < 0 && err != FDT_ERR_EXISTS) {
> > >
> > > This FDT_ERR_EXISTS error code is possibly returned by:
> > >
> > > node = fdt_add_subnode(blob, parent, name);
> > > if (node < 0)
> > > return node;
> > >
> > > But if it exists, I believe fdtdec_add_reserved_memory() already
> > > returns 0 because they are likely to have the same range of memory
> > > block start address and size, no?
> > >
> >
> > Currently, yes. As libfdt and fdtdec_add_reserved_memory external to
> > this code, functionality
> > can change without modifying fdt_fixup.c knowingly or unknowingly.
> > FDT_ERR_EXISTS is harmless error in this context and we shouldn't
> > cause boot failure because of that.
> > That's why I add that exclusion.
>
> Okay. But the error should be checked against -FDT_ERR_EXISTS.
>
My bad. I will fix it and send the next version.
> Regards,
> Bin
--
Regards,
Atish
[PATCH v2] arm64: issue ISB after updating system registers
ARM Architecture reference manual clearly states that PE pipeline
should be flushed after any change to system registers. Refer to
paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture
Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI
0487B.a).
Failing to issue instruction memory synchronization barrier can lead
to spurious errors, like synchronous exception when accessing FPU
registers. This is very prominent on CPUs with long instruction
pipeline, like ARM Cortex A72.
This change fixes the following U-Boot panic:
"Synchronous Abort" handler, esr 0x1fe0
elr: 800948cc lr : 80091e04
x0 : 801ffdc8 x1 : 00c8
x2 : 800979d4 x3 : 801ffc60
x4 : 801ffd40 x5 : ff80ffd8
x6 : 801ffd70 x7 : 801ffd70
x8 : 000a x9 :
x10: 0044 x11:
x12: x13:
x14: x15:
x16: 8008b2e0 x17:
x18: 801ffec0 x19: 800957b0
x20: 00c8 x21: 801ffdc8
x22: 8009909e x23:
x24: x25:
x26: x27:
x28: x29: 801ffc50
Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0)
While executing instruction
str q0, [sp, #112]
in vsnprintf() prologue. This panic was observed only on Cortex A72 so
far.
This patch places ISBs on other strategic places as well.
Also, this probably is the right fix for the issue workarounded in the
commit 45f41c13 ("ARM: uniphier: add weird workaround code for LD20")
Reported-by: Oleksandr Andrushchenko
Suggested-by: Julien Grall
Signed-off-by: Volodymyr Babchuk
CC: Tom Rini
CC: Masahiro Yamada
CC: Stefano Stabellini
--
Changes from v1:
- Added ISBs under CONFIG_ARMV8_SET_SMPEN and erratas.
- Added Stefano, Julien and Oleksandr
---
arch/arm/cpu/armv8/start.S | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 99d126660d..002698b501 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -120,6 +120,7 @@ pie_fixup_done:
mov x0, #3 << 20
msr cpacr_el1, x0 /* Enable FP/SIMD */
0:
+ isb
/*
* Enable SMPEN bit for coherency.
@@ -132,6 +133,7 @@ pie_fixup_done:
mrs x0, S3_1_c15_c2_1 /* cpuectlr_el1 */
orr x0, x0, #0x40
msr S3_1_c15_c2_1, x0
+ isb
1:
#endif
@@ -233,6 +235,7 @@ apply_a53_core_errata:
/* Enable data cache clean as data cache clean/invalidate */
orr x0, x0, #1 << 44
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
+ isb
#endif
b 0b
@@ -247,6 +250,7 @@ apply_a57_core_errata:
/* Disable write streaming no-allocate threshold */
orr x0, x0, #3 << 27
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
+ isb
#endif
#ifdef CONFIG_ARM_ERRATA_826974
@@ -254,6 +258,7 @@ apply_a57_core_errata:
/* Disable speculative load execution ahead of a DMB */
orr x0, x0, #1 << 59
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
+ isb
#endif
#ifdef CONFIG_ARM_ERRATA_833471
@@ -263,6 +268,7 @@ apply_a57_core_errata:
could impact performance. */
orr x0, x0, #1 << 38
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
+ isb
#endif
#ifdef CONFIG_ARM_ERRATA_829520
@@ -273,6 +279,7 @@ apply_a57_core_errata:
could impact performance. */
orr x0, x0, #1 << 4
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
+ isb
#endif
#ifdef CONFIG_ARM_ERRATA_833069
@@ -280,6 +287,7 @@ apply_a57_core_errata:
/* Disable Enable Invalidates of BTB bit */
and x0, x0, #0xE
msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
+ isb
#endif
b 0b
ENDPROC(apply_core_errata)
--
2.27.0
Re: [PATCH v4 3/4] riscv: cpu: fixes to display proper CPU features
Hi Bin, On Tue, 23 Jun 2020 at 19:26, Bin Meng wrote: > > Hi Simon, > > On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam > wrote: > > > > The cmd "cpu detail" fetches uninitialized cpu feature information > > and thus displays wrong / inconsitent details as below. FU540-C000 doesn't > > have any microcode, yet the cmd display's it. > > => cpu detail > > 0: cpu@0 rv64imac > > ID = 0, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > > Microcode version 0x0 > > Device ID 0x0 > > 1: cpu@1 rv64imafdc > > ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > > Microcode version 0x0 > > Device ID 0x0 > > 2: cpu@2 rv64imafdc > > ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > > Microcode version 0x0 > > Device ID 0x0 > > 3: cpu@3 rv64imafdc > > ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > > Microcode version 0x0 > > Device ID 0x0 > > 4: cpu@4 rv64imafdc > > ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > > Microcode version 0x0 > > Device ID 0x0 > > > > The L1 cache or MMU entry seen above is also displayed inconsistently. > > So initialize features to zero before fetching from device tree. > > Additionally the conditional check to read "mmu-type" from device tree > > is not rightly handled due to which the cpu feature doesn't include > > CPU_FEAT_MMU even if it's corresponding entry is present in device tree. > > > > We now see correct features as: > > > > => cpu detail > > 0: cpu@0 rv64imac > > ID = 0, freq = 999.100 MHz > > 1: cpu@1 rv64imafdc > > ID = 1, freq = 999.100 MHz: MMU > > 2: cpu@2 rv64imafdc > > ID = 2, freq = 999.100 MHz: MMU > > 3: cpu@3 rv64imafdc > > ID = 3, freq = 999.100 MHz: MMU > > 4: cpu@4 rv64imafdc > > ID = 4, freq = 999.100 MHz: MMU > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > --- > > drivers/cpu/riscv_cpu.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c > > index 76b0489..8c4b5e7 100644 > > --- a/drivers/cpu/riscv_cpu.c > > +++ b/drivers/cpu/riscv_cpu.c > > @@ -38,6 +38,8 @@ static int riscv_cpu_get_info(struct udevice *dev, struct > > cpu_info *info) > > > > /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */ > > info->cpu_freq = 0; > > + /* Initialise cpu features before updating from device tree */ > > + info->features = 0; > > For this one, do you think we should fix the cpu_get_info() in > cpu-uclass driver instead? With fix in the cpu-uclass driver we can > avoid similar issue in any single CPU driver. Yes it would be best to fix that function to zero the data. Regards, Simon
Re: [PATCH 1/5] dt-bindings: prci: add indexes for reset signals available in prci
On Mon, Jun 22, 2020 at 8:28 PM Sagar Shrikant Kadam wrote: > > Add bit indexes for reset signals within the PRCI module > on FU540-C000 SoC. > The DDR and ethernet sub-system's have reset signals > indicated by these reset indexes. > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > include/dt-bindings/clock/sifive-fu540-prci.h | 8 > 1 file changed, 8 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Bin > Hi Rick, > > On Wed, Jun 24, 2020 at 9:36 AM Rick Chen wrote: > > > > Hi Sagar > > > > > > > > Hello Rick, > > > > > > > -Original Message- > > > > From: Rick Chen > > > > Sent: Monday, June 22, 2020 7:24 AM > > > > To: Sagar Kadam > > > > Cc: U-Boot Mailing List ; Lukasz Majewski > > > > ; Bin Meng ; Jagan Teki > > > > ; Pragnesh Patel > > > > ; Anup Patel ; Simon > > > > Glass ; Sean Anderson ; rick > > > > ; Alan Kao ; > > > > ycli...@andestech.com > > > > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock > > > > handlers > > > > > > > > [External Email] Do not click links or attachments unless you recognize > > > > the > > > > sender and know the content is safe > > > > > > > > Hi Sagar, > > > > > > > > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com] > > > > > Sent: Sunday, June 21, 2020 9:10 PM > > > > > To: u-boot@lists.denx.de > > > > > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com; > > > > > ja...@amarulasolutions.com; pragnesh.pa...@sifive.com; > > > > > anup.pa...@wdc.com; s...@chromium.org; sean...@gmail.com; Sagar > > > > > Shrikant Kadam > > > > > Subject: [PATCH v4 1/4] fu540: prci: add request and free clock > > > > > handlers > > > > > > > > > > Add clk_request handler to check if a valid clock is requested. > > > > > Here clk_free handler is added for debug purpose which will display > > > > details of clock passed to clk_free. > > > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > > Reviewed-by: Pragnesh Patel > > > > > --- > > > > > > > > This v4 series still have some conflicts with master. > > > > Please check about it. > > > > > > > > Applying: fu540: prci: add request and free clock handlers > > > > Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases > > > > Applying: riscv: cpu: fixes to display proper CPU features > > > > error: patch failed: drivers/cpu/riscv_cpu.c:38 > > > > error: drivers/cpu/riscv_cpu.c: patch does not apply Patch failed at > > > > 0003 > > > > riscv: cpu: fixes to display proper CPU features > > > > > > > > > > Thanks for trying this out > > > This series is dependent on following two patches [1] > > > and [2] below which are part of "Add Sipeed Maix support." series > > > [1] https://patchwork.ozlabs.org/patch/1295345 > > > [2] https://patchwork.ozlabs.org/patch/1295346 > > > and I also mentioned in cover-letter. Sorry If I missed to add some > > > additional information there. > > > > > > The dependent are added like > > > -u-boot master [commit 2b8692bac1e8]. > > > -Patches [1] + [2]. > > > -This series. > > > > According to this dependency I will apply yours in -next behind of Sean's > > I just sent comments to this series, please hold on. OK. Thanks, Rick > > Regards, > Bin
Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Rick, On Wed, Jun 24, 2020 at 9:36 AM Rick Chen wrote: > > Hi Sagar > > > > > Hello Rick, > > > > > -Original Message- > > > From: Rick Chen > > > Sent: Monday, June 22, 2020 7:24 AM > > > To: Sagar Kadam > > > Cc: U-Boot Mailing List ; Lukasz Majewski > > > ; Bin Meng ; Jagan Teki > > > ; Pragnesh Patel > > > ; Anup Patel ; Simon > > > Glass ; Sean Anderson ; rick > > > ; Alan Kao ; > > > ycli...@andestech.com > > > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock > > > handlers > > > > > > [External Email] Do not click links or attachments unless you recognize > > > the > > > sender and know the content is safe > > > > > > Hi Sagar, > > > > > > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com] > > > > Sent: Sunday, June 21, 2020 9:10 PM > > > > To: u-boot@lists.denx.de > > > > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com; > > > > ja...@amarulasolutions.com; pragnesh.pa...@sifive.com; > > > > anup.pa...@wdc.com; s...@chromium.org; sean...@gmail.com; Sagar > > > > Shrikant Kadam > > > > Subject: [PATCH v4 1/4] fu540: prci: add request and free clock > > > > handlers > > > > > > > > Add clk_request handler to check if a valid clock is requested. > > > > Here clk_free handler is added for debug purpose which will display > > > details of clock passed to clk_free. > > > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > > Reviewed-by: Pragnesh Patel > > > > --- > > > > > > This v4 series still have some conflicts with master. > > > Please check about it. > > > > > > Applying: fu540: prci: add request and free clock handlers > > > Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases > > > Applying: riscv: cpu: fixes to display proper CPU features > > > error: patch failed: drivers/cpu/riscv_cpu.c:38 > > > error: drivers/cpu/riscv_cpu.c: patch does not apply Patch failed at 0003 > > > riscv: cpu: fixes to display proper CPU features > > > > > > > Thanks for trying this out > > This series is dependent on following two patches [1] > > and [2] below which are part of "Add Sipeed Maix support." series > > [1] https://patchwork.ozlabs.org/patch/1295345 > > [2] https://patchwork.ozlabs.org/patch/1295346 > > and I also mentioned in cover-letter. Sorry If I missed to add some > > additional information there. > > > > The dependent are added like > > -u-boot master [commit 2b8692bac1e8]. > > -Patches [1] + [2]. > > -This series. > > According to this dependency I will apply yours in -next behind of Sean's I just sent comments to this series, please hold on. Regards, Bin
RE: [PATCH v4] mmc: sdhci: Fix HISPD bit handling
All:
> Subject: Re: [PATCH v4] mmc: sdhci: Fix HISPD bit handling
>
> On 6/22/20 6:26 PM, Jagan Teki wrote:
> > On Mon, Jun 22, 2020 at 2:54 PM Jaehoon Chung
> wrote:
> >>
> >> Hi Peng,
> >>
> >> On 6/22/20 10:49 AM, Peng Fan wrote:
> >>> Jaehoon,
> >>>
> Subject: [PATCH v4] mmc: sdhci: Fix HISPD bit handling
> >>>
> >>> Are you fine with this v4?
> >>
> >> Thanks for sharing it. i didn't see patch v4.
> >>
> >>>
> >>> Thanks,
> >>> Peng.
> >>>
>
> SDHCI HISPD bits need to be configured based on desired mmc timings
> mode and some HISPD quirks.
>
> So, handle the HISPD bit based on the mmc computed selected
> mode(timing
> parameter) rather than fixed mmc card clock frequency.
>
> Linux handle the HISPD similar like this in below commit but no
> SDHCI_QUIRK_BROKEN_HISPD_MODE,
>
> commit <501639bf2173> ("mmc: sdhci: fix
> SDHCI_QUIRK_NO_HISPD_BIT
> handling")
>
> This eventually fixed the mmc write issue observed in
> rk3399 sdhci controller.
>
> Bug log for refernece,
> => gpt write mmc 0 $partitions
> Writing GPT: mmc write failed
> ** Can't write to device 0 **
> ** Can't write to device 0 **
> error!
>
> Cc: Kever Yang
> Cc: Peng Fan
> Tested-by: Suniel Mahesh #
> roc-rk3399-pc
> Signed-off-by: Jagan Teki
> ---
> Changes for v4:
> - update commit message
> - simplify the logic.
>
> drivers/mmc/sdhci.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> 92cc8434af..6cb702111b 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -567,6 +567,7 @@ static int sdhci_set_ios(struct mmc *mmc)
> #endif
> u32 ctrl;
> struct sdhci_host *host = mmc->priv;
> +bool no_hispd_bit = false;
>
> if (host->ops && host->ops->set_control_reg)
> host->ops->set_control_reg(host); @@ -594,14
> +595,24
> @@ static int sdhci_set_ios(struct mmc *mmc)
> ctrl &= ~SDHCI_CTRL_4BITBUS;
> }
>
> -if (mmc->clock > 2600)
> -ctrl |= SDHCI_CTRL_HISPD;
> -else
> -ctrl &= ~SDHCI_CTRL_HISPD;
> -
> if ((host->quirks & SDHCI_QUIRK_NO_HISPD_BIT) ||
> (host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE))
> -ctrl &= ~SDHCI_CTRL_HISPD;
> +no_hispd_bit = true;
> >>
> >> No. ctrl variable is set to bit[2] of HOST_CONTROL register.
> >> But Some samsung SoCs are using its bit[2] as other purpose.
> >> So it needs to revert the value with "ctrl &= ~SDHCI_CTRL_HISPD".
> >> Because it's possible to set to 1.
> >>
> >> SDHCI_QUIRK_NO_HISPD_BIT means that it's used other purpose.
> >
> > So, what are you suggesting? could you please elaborate?
>
>
> if ((host->quirks & SDHCI_QUIRK_NO_HISPD_BIT) ||
> (host->quirks & SDHCI_QUIRK_NO_BROKEN_HISPD_MODE)) {
> ctrl &= ~SDHCI_CTRL_HISPD;
> no_hispd_bit = true;
> }
>
> Just adding "ctrl &= ~SDHCI_CTRL_HISPD;" into its condition.
I pushed this patch with the upper code added to my CI
with a update in commit log:
https://travis-ci.org/github/MrVan/u-boot/builds/701486010
Please let me know if any objections.
Thanks,
Peng.
> Then it's helpful to me.
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Jagan.
> >
Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Sagar
>
> Hello Rick,
>
> > -Original Message-
> > From: Rick Chen
> > Sent: Monday, June 22, 2020 7:24 AM
> > To: Sagar Kadam
> > Cc: U-Boot Mailing List ; Lukasz Majewski
> > ; Bin Meng ; Jagan Teki
> > ; Pragnesh Patel
> > ; Anup Patel ; Simon
> > Glass ; Sean Anderson ; rick
> > ; Alan Kao ;
> > ycli...@andestech.com
> > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
> >
> > [External Email] Do not click links or attachments unless you recognize the
> > sender and know the content is safe
> >
> > Hi Sagar,
> >
> > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> > > Sent: Sunday, June 21, 2020 9:10 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com;
> > > ja...@amarulasolutions.com; pragnesh.pa...@sifive.com;
> > > anup.pa...@wdc.com; s...@chromium.org; sean...@gmail.com; Sagar
> > > Shrikant Kadam
> > > Subject: [PATCH v4 1/4] fu540: prci: add request and free clock
> > > handlers
> > >
> > > Add clk_request handler to check if a valid clock is requested.
> > > Here clk_free handler is added for debug purpose which will display
> > details of clock passed to clk_free.
> > >
> > > Signed-off-by: Sagar Shrikant Kadam
> > > Reviewed-by: Pragnesh Patel
> > > ---
> >
> > This v4 series still have some conflicts with master.
> > Please check about it.
> >
> > Applying: fu540: prci: add request and free clock handlers
> > Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases
> > Applying: riscv: cpu: fixes to display proper CPU features
> > error: patch failed: drivers/cpu/riscv_cpu.c:38
> > error: drivers/cpu/riscv_cpu.c: patch does not apply Patch failed at 0003
> > riscv: cpu: fixes to display proper CPU features
> >
>
> Thanks for trying this out
> This series is dependent on following two patches [1]
> and [2] below which are part of "Add Sipeed Maix support." series
> [1] https://patchwork.ozlabs.org/patch/1295345
> [2] https://patchwork.ozlabs.org/patch/1295346
> and I also mentioned in cover-letter. Sorry If I missed to add some
> additional information there.
>
> The dependent are added like
> -u-boot master [commit 2b8692bac1e8].
> -Patches [1] + [2].
> -This series.
According to this dependency I will apply yours in -next behind of Sean's
Thanks,
Rick
>
> I guess the PR for the series was sent earlier followed with some discussion
> https://www.mail-archive.com/u-boot@lists.denx.de/msg370739.html
> and I think this series was deferred in that PR.
> Please let me know if you have some suggestions here?
>
> Thanks & BR,
> Sagar Kadam
>
> > Thanks,
> > Rick
> >
> > > drivers/clk/sifive/fu540-prci.c | 21 +
> > > 1 file changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/clk/sifive/fu540-prci.c
> > > b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> > > --- a/drivers/clk/sifive/fu540-prci.c
> > > +++ b/drivers/clk/sifive/fu540-prci.c
> > > @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk
> > *clk, ulong rate)
> > > return rate;
> > > }
> > >
> > > +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> > > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > > + clk->id);
> > > +
> > > + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > > + return -EINVAL;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > > + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > > + clk->id);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int sifive_fu540_prci_enable(struct clk *clk) {
> > > struct __prci_clock *pc;
> > > @@ -755,6 +774,8 @@ static struct clk_ops sifive_fu540_prci_ops = {
> > > .get_rate = sifive_fu540_prci_get_rate,
> > > .enable = sifive_fu540_prci_enable,
> > > .disable = sifive_fu540_prci_disable,
> > > + .request = sifive_fu540_prci_clk_request,
> > > + .rfree= sifive_fu540_prci_clk_free,
> > > };
> > >
> > > static const struct udevice_id sifive_fu540_prci_ids[] = {
> > > --
> > > 2.7.4
> > >
Re: [U-Boot] Pull request: u-boot-riscv/master
Hi Sean Tom Rini 於 2020年6月23日 週二 上午8:45寫道： > > On Mon, Jun 22, 2020 at 02:03:52PM +0800, Rick Chen wrote: > > Hi Tom > > > > > From: Tom Rini [mailto:tr...@konsulko.com] > > > Sent: Monday, May 25, 2020 11:40 PM > > > To: Open Source Project uboot > > > Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) > > > Subject: Re: [U-Boot] Pull request: u-boot-riscv/master > > > > > > On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote: > > > > > > > Hi Tom, > > > > > > > > Please pull some riscv updates: > > > > > > > > - Add Sipeed Maix support. > > > > - sifive: fix palmer's email address. > > > > - Move all SMP related SBI calls to SBI_v01. > > > > > > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926 > > > > > > > > Thanks > > > > Rick > > > > > > > > > > > > The following changes since commit > > > > 9c5fef577494769e3ff07952a85f9b7125ef765b: > > > > > > > > Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400) > > > > > > > > are available in the Git repository at: > > > > > > > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > > > > > > > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607: > > > > > > > > riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800) > > > > > > > > > > There's too many generic changes in this PR for this late in the cycle, > > > for things I gather related to the Maix platform. All of the clk and DM > > > changes impact virtually all platforms. Please re-do this PR to drop the > > > Maix platform support for now, and resubmit that for -next, which I will > > > be opening shortly. Everything else however is good for master. > > > > May I ask for your suggestions about this patch series about "riscv: > > Add Sipeed Maix support " ? > > Shall I send a PR include this patch series in early release cycle or > > shall I suggest Sean to re-edit this patch series for less generic > > changes which may bring virtual impacts? > > So I looked over the generic changes again. There's no other way to > support the platform without those type of changes, yes? If so, yes, > lets put it in to -next. Please rebase -next for upstream There are some conflicts needed to be fixed. Applying: clk: Always use the supplied struct clk Applying: clk: Check that ops of composite clock components exist before calling Applying: clk: Unconditionally recursively en-/dis-able clocks Applying: clk: Fix clk_get_by_* handling of index Applying: clk: Add K210 pll support Applying: clk: Add a bypass clock for K210 Applying: clk: Add K210 clock support Applying: dm: Add support for simple-pm-bus Applying: dm: Fix error handling for dev_read_addr_ptr Applying: reset: Add generic reset driver error: patch failed: configs/sandbox_defconfig:196 error: configs/sandbox_defconfig: patch does not apply Patch failed at 0010 reset: Add generic reset driver Thanks, Rick > > -- > Tom
Re: [PATCH v4 4/4] riscv: cpu: check and append L1 cache to cpu features
On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam wrote: > > All cpu cores within FU540-C000 having split I/D caches. > Set the L1 cache feature bit using the i-cache-size as one of the > property from device tree indicating that L1 cache is present > on the cpu core. > > => cpu detail > 0: cpu@0 rv64imac > ID = 0, freq = 999.100 MHz: L1 cache > 1: cpu@1 rv64imafdc > ID = 1, freq = 999.100 MHz: L1 cache, MMU > 2: cpu@2 rv64imafdc > ID = 2, freq = 999.100 MHz: L1 cache, MMU > 3: cpu@3 rv64imafdc > ID = 3, freq = 999.100 MHz: L1 cache, MMU > 4: cpu@4 rv64imafdc > ID = 4, freq = 999.100 MHz: L1 cache, MMU > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > drivers/cpu/riscv_cpu.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c > index 8c4b5e7..ce722cb 100644 > --- a/drivers/cpu/riscv_cpu.c > +++ b/drivers/cpu/riscv_cpu.c > @@ -35,6 +35,7 @@ static int riscv_cpu_get_info(struct udevice *dev, struct > cpu_info *info) > int ret; > struct clk clk; > const char *mmu; > + u32 split_cache_size; > > /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */ > info->cpu_freq = 0; > @@ -57,6 +58,11 @@ static int riscv_cpu_get_info(struct udevice *dev, struct > cpu_info *info) > if (mmu) > info->features |= BIT(CPU_FEAT_MMU); > > + /* check if I/D cache is present */ > + ret = dev_read_u32(dev, "i-cache-size", _cache_size); What about testing either "i-cache-size" and "d-cache-size", and if either one exists, set CPU_FEAT_L1_CACHE > + if (!ret) > + info->features |= BIT(CPU_FEAT_L1_CACHE); > + > return 0; > } Regards, Bin
Re: [PATCH v4 3/4] riscv: cpu: fixes to display proper CPU features
Hi Simon, On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam wrote: > > The cmd "cpu detail" fetches uninitialized cpu feature information > and thus displays wrong / inconsitent details as below. FU540-C000 doesn't > have any microcode, yet the cmd display's it. > => cpu detail > 0: cpu@0 rv64imac > ID = 0, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > Microcode version 0x0 > Device ID 0x0 > 1: cpu@1 rv64imafdc > ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > Microcode version 0x0 > Device ID 0x0 > 2: cpu@2 rv64imafdc > ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > Microcode version 0x0 > Device ID 0x0 > 3: cpu@3 rv64imafdc > ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > Microcode version 0x0 > Device ID 0x0 > 4: cpu@4 rv64imafdc > ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID > Microcode version 0x0 > Device ID 0x0 > > The L1 cache or MMU entry seen above is also displayed inconsistently. > So initialize features to zero before fetching from device tree. > Additionally the conditional check to read "mmu-type" from device tree > is not rightly handled due to which the cpu feature doesn't include > CPU_FEAT_MMU even if it's corresponding entry is present in device tree. > > We now see correct features as: > > => cpu detail > 0: cpu@0 rv64imac > ID = 0, freq = 999.100 MHz > 1: cpu@1 rv64imafdc > ID = 1, freq = 999.100 MHz: MMU > 2: cpu@2 rv64imafdc > ID = 2, freq = 999.100 MHz: MMU > 3: cpu@3 rv64imafdc > ID = 3, freq = 999.100 MHz: MMU > 4: cpu@4 rv64imafdc > ID = 4, freq = 999.100 MHz: MMU > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > drivers/cpu/riscv_cpu.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c > index 76b0489..8c4b5e7 100644 > --- a/drivers/cpu/riscv_cpu.c > +++ b/drivers/cpu/riscv_cpu.c > @@ -38,6 +38,8 @@ static int riscv_cpu_get_info(struct udevice *dev, struct > cpu_info *info) > > /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */ > info->cpu_freq = 0; > + /* Initialise cpu features before updating from device tree */ > + info->features = 0; For this one, do you think we should fix the cpu_get_info() in cpu-uclass driver instead? With fix in the cpu-uclass driver we can avoid similar issue in any single CPU driver. > > /* First try getting the frequency from the assigned clock */ > ret = clk_get_by_index(dev, 0, ); > @@ -52,7 +54,7 @@ static int riscv_cpu_get_info(struct udevice *dev, struct > cpu_info *info) > dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq); > > mmu = dev_read_string(dev, "mmu-type"); > - if (!mmu) > + if (mmu) > info->features |= BIT(CPU_FEAT_MMU); > > return 0; Regards, Bin
Re: [PATCH v4 2/4] riscv: dts: hifive-unleashed-a00: add cpu aliases
Hi Sagar, On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam wrote: > > Add cpu aliases to U-Boot specific dtsi for hifive-unleashed. > Without aliases we see that the CPU device sequence numbers are set > randomly and the cpu list/detail command will show it as follows: > => cpu list > 1: cpu@0 rv64imac > 0: cpu@1 rv64imafdc > 2: cpu@2 rv64imafdc > 3: cpu@3 rv64imafdc > 4: cpu@4 rv64imafdc Without this patch, my output does not show the cpu@0 node in the "cpu list" output. Could you please clarify? > > Seems like CPU probing with dm-model also relies on aliases as observed > in case spi. The fu540-c000-u-boot.dtsi has cpu0/1/2/3/4 nodes and so > adding corresponding aliases we can ensure that cpu devices are assigned > proper sequence as follows: > => cpu list > 0: cpu@0 rv64imac > 1: cpu@1 rv64imafdc > 2: cpu@2 rv64imafdc > 3: cpu@3 rv64imafdc > 4: cpu@4 rv64imafdc > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- Regards, Bin
Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
Hi Sagar,
On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam
wrote:
>
> Add clk_request handler to check if a valid clock is requested.
> Here clk_free handler is added for debug purpose which will display
> details of clock passed to clk_free.
>
> Signed-off-by: Sagar Shrikant Kadam
> Reviewed-by: Pragnesh Patel
> ---
> drivers/clk/sifive/fu540-prci.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
> index fe6e0d4..9a9ff6b 100644
> --- a/drivers/clk/sifive/fu540-prci.c
> +++ b/drivers/clk/sifive/fu540-prci.c
> @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk *clk,
> ulong rate)
> return rate;
> }
>
> +static int sifive_fu540_prci_clk_request(struct clk *clk)
> +{
> + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> + clk->id);
> +
> + if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int sifive_fu540_prci_clk_free(struct clk *clk)
> +{
> + debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> + clk->id);
> +
> + return 0;
> +}
It seems these 2 routines do not actually do anything? Is this for
debugging purposes?
Regards,
Bin
Re: [PATCH v4 0/4] update clock handler and proper cpu features
Hi Sagar,
On Sun, Jun 21, 2020 at 9:10 PM Sagar Shrikant Kadam
wrote:
>
> U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing
> clk_request and free handlers.
> The current "cpu detail" sometimes shows "Microcode" as a feature, which
> is not the case with FU540-C000 on HiFive Unleashed board.
>
> Patch 1: add clk request handler to check if valid clock id is requested.
> Patch 2: add cpu node aliases.
> Patch 3: Correctly parse and update mmu-type.
>
> RISC-V core's on FU540-C000 SoC have separate instruction and data (split)
> L1 cache.
> Patch 4:Use i-cache-size dt property as one of identifier to indicate a
> split cache is available.
>
> I have picked few dependent patches from Sean's series from here [1]
> and [2].
>
> These have applied on mainline U-Boot commit 2b8692bac1e8 ("Merge tag
> 'efi-2020-07-rc5-2' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi;)
>
> Patch history:
> =
> V4:
> 1. Rebased the series to mainline commit.
> 2. Updated dependency list as few patches are now merged.
> 3. Added U-Boot log of the flow i.e fsbl + fw_payload.bin (Opensbi+U-Boot)
>
> V3:
> 1. Included the cosmetic change as suggested
>s/L1 feature/L1 cache feature/
> 2. Added Reviewed-By tags
>
> V2:
> 1. Incorporate review comments from Bin and Sean Anderson.
>and dropped 2nd patch as similar work was already done in [1] and [2]
> 2 Add cpu node aliases to display cpu node's in sequence.
> 3. Add fix to show mmu as available cpu feature.
> 4. Check and append L1 cache feature.
>
> V1: Base version
> Thanks to Vincent Chen for testing the V1
> version of this series.
>
> [1] https://patchwork.ozlabs.org/patch/1295345
> [2] https://patchwork.ozlabs.org/patch/1295346
>
> All these together is available here:
> https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v4
>
> U-Boot log:
> ===
> SiFive FSBL: 2020-02-19-1081db9-dirty
> Using new FSBL DTB now
> HiFive-U-serial-#: 02c8
> Loading boot payload
>
> OpenSBI v0.7-31-gd626037
>_ _
> / __ \ / | _ \_ _|
> | | | |_ __ ___ _ __ | (___ | |_) || |
> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> | |__| | |_) | __/ | | |) | |_) || |_
> \/| .__/ \___|_| |_|_/|/_|
> | |
> |_|
>
> Platform Name : SiFive Freedom U540
> Platform HART Features : RV64ACDFIMSU
> Platform HART Count: 4
> Current HART ID: 1
> Firmware Base : 0x8000
> Firmware Size : 100 KB
> Runtime SBI Version: 0.2
>
> MIDELEG : 0x0222
> MEDELEG : 0xb109
> PMP0: 0x8000-0x8001 (A)
> PMP1: 0x-0x007f (A,R,W,X)
>
>
> U-Boot 2020.07-rc4-00084-gf824d2c (Jun 21 2020 - 04:58:40 -0700)
>
> CPU: rv64imac
> Model: SiFive HiFive Unleashed A00
> DRAM: 8 GiB
> MMC: spi@1005:mmc@0: 0
> In:serial@1001
> Out: serial@1001
> Err: serial@1001
> Net: eth0: ethernet@1009
> Hit any key to stop autoboot: 0
> => cpu detail
> 0: cpu@0 rv64imac
> ID = 0, freq = 999.100 MHz: L1 cache
> 1: cpu@1 rv64imafdc
> ID = 1, freq = 999.100 MHz: L1 cache, MMU
> 2: cpu@2 rv64imafdc
> ID = 2, freq = 999.100 MHz: L1 cache, MMU
> 3: cpu@3 rv64imafdc
> ID = 3, freq = 999.100 MHz: L1 cache, MMU
> 4: cpu@4 rv64imafdc
> ID = 4, freq = 999.100 MHz: L1 cache, MMU
> =>
>
It's strange that I am seeing different output without your patch:
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
0: cpu@3 rv64imafdc
3: cpu@4 rv64imafdc
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 12 Hz: L1 cache
2: cpu@2 rv64imafdc
ID = 2, freq = 12 Hz: L1 cache
0: cpu@3 rv64imafdc
ID = 3, freq = 12 Hz: L1 cache
3: cpu@4 rv64imafdc
ID = 4, freq = 12 Hz: L1 cache
It looks like your patch included the E51 core (hartid 0) in the output?
Regards,
Bin
Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
Hi Pragnesh > From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > Sent: Friday, May 29, 2020 2:45 PM > To: u-boot@lists.denx.de > Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; > paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick > Jian-Zhi Chen(陳建志); Pragnesh Patel; Palmer Dabbelt > Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver > > This patch enables SiFive PWM driver for the SiFive Unleashed board. > > Signed-off-by: Pragnesh Patel > --- > board/sifive/fu540/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index > 86193d7668..683668d059 100644 > --- a/board/sifive/fu540/Kconfig > +++ b/board/sifive/fu540/Kconfig > @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy > imply SMP > imply MISC > imply SIFIVE_OTP > + imply DM_PWM > + imply PWM_SIFIVE > This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive. It is weird to introduce here and not appropriate to depend on another patch. Thanks, Rick > endif > -- > 2.17.1
Re: [linux-sunxi] Re: [RFC PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40
On 24/06/2020 01:34, Icenowy Zheng wrote:
Hi,
> 于 2020年6月24日 GMT+08:00 上午8:28:39, "André Przywara"
> 写到:
>> On 19/06/2020 13:16, Icenowy Zheng wrote:
>>
>> Hi Icenowy,
>>
>>> Previously we have known that R40 has a configuration register for
>> its
>>> rank 1, which allows different configuration than rank 0. Reverse
>>> engineering of newest libdram of A64 from Allwinner shows that A64
>> has
>>> this register too. It's bit 0 (which enables dual rank in rank 0
>>> configuration register) means a dedicated rank size setup is used for
>>> rank 1.
>>
>> Ah! That's a nice discovery, as it probably explains how my Eachlink H6
>> TV box works with its asymmetric 3GB DRAM config!
>
> Wait. The configuration of H6 DRAM controller is totally different. it uses
> ADDRMAP registers in DRAM controller, instead of specifying parameters
> in MCTL_COM part.
I see, but at least it confirms that configuring the two ranks
differently is possible. I was always scratching my head how the box
works with two different set of chips (four 4GBit chips and four 2Gbit
chips). Do we support this asymmetric setup for the H6 controller
already, possibly due to the different way of setting this up?
If not I can check out if boot0 does some magic there.
Cheers,
Andre
>
>>
>>> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
>>> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
>>> DRAM support necessary.
>>>
>>> Add this support. As we have gained knowledge of asymmetric dual
>> rank,
>>> we can now allow R40 dual rank memory setup to work too.
>>>
>>> Signed-off-by: Icenowy Zheng
>>> ---
>>> Testing on R40 boards and A64 single rank boards (e.g. the original
>> Pine
>>> A64+) is welcomed. I have these boards, but I get too lazy to take
>> them
>>> out and test them.
>>
>> I briefly tested this on a Bananapi M2 Berry (R40, 1GB), Pine64 512MB
>> and Pine64+ 2GB. All three boot happily into U-Boot, tested the Pine64+
>> to the Linux prompt as well.
>>
>> I will do a proper review shortly.
>>
>> Thanks for the patch!
>>
>> Cheers,
>> Andre
>>
>>>
>>> .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +-
>>> arch/arm/mach-sunxi/dram_sunxi_dw.c | 100
>> +-
>>> 2 files changed, 84 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>>> index a5a7ebde44..e843c14202 100644
>>> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>>> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
>>> #define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
>>> /* The eight data lines (DQn) plus DM, DQS and DQSN */
>>> #define LINES_PER_BYTE_LANE(BITS_PER_BYTE + 3)
>>> -struct dram_para {
>>> +
>>> +struct rank_para {
>>> u16 page_size;
>>> - u8 bus_full_width;
>>> - u8 dual_rank;
>>> u8 row_bits;
>>> u8 bank_bits;
>>> +};
>>> +
>>> +struct dram_para {
>>> + u8 dual_rank;
>>> + u8 bus_full_width;
>>> + struct rank_para ranks[2];
>>> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>>> const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>>> const u8 ac_delays[31];
>>> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>>> index a462538521..7a40d92349 100644
>>> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>>> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>>> @@ -349,18 +349,24 @@ static void mctl_set_cr(uint16_t socid, struct
>> dram_para *para)
>>> #else
>>> #error Unsupported DRAM type!
>>> #endif
>>> - (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>> MCTL_CR_FOUR_BANKS) |
>>> + (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>> MCTL_CR_FOUR_BANKS) |
>>>MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>>>(para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK)
>> |
>>> - MCTL_CR_PAGE_SIZE(para->page_size) |
>>> - MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
>>> + MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
>>> + MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
>>>
>>> - if (socid == SOCID_R40) {
>>> - if (para->dual_rank)
>>> - panic("Dual rank memory not supported\n");
>>> + if (socid == SOCID_A64 || socid == SOCID_R40) {
>>> + writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>> MCTL_CR_FOUR_BANKS) |
>>> + MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>>> + (para->dual_rank ? MCTL_CR_DUAL_RANK :
>>> MCTL_CR_SINGLE_RANK)
>> |
>>> + MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
>>> + MCTL_CR_ROW_BITS(para->ranks[1].row_bits),
>> _com->cr_r1);
>>> + }
>>>
>>> + if (socid == SOCID_R40) {
>>> /* Mux pin to A15 address line for single rank memory. */
>>> - setbits_le32(_com->cr_r1,
Re: [PATCH 1/3] riscv: Do not return error if reserved node already exists
Hi Atish,
On Wed, Jun 24, 2020 at 2:17 AM Atish Patra wrote:
>
> On Tue, Jun 23, 2020 at 12:24 AM Bin Meng wrote:
> >
> > Hi Atish,
> >
> > On Fri, Jun 19, 2020 at 9:52 AM Atish Patra wrote:
> > >
> > > Not all errors are fatal. If a reserved memory node already exists in the
> > > destination device tree, we can continue to boot without failing.
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > arch/riscv/lib/fdt_fixup.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> > > index 6db48ad04a56..91524d9a5ae9 100644
> > > --- a/arch/riscv/lib/fdt_fixup.c
> > > +++ b/arch/riscv/lib/fdt_fixup.c
> > > @@ -62,7 +62,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void
> > > *dst)
> > > pmp_mem.end = addr + size - 1;
> > > err = fdtdec_add_reserved_memory(dst, basename, _mem,
> > > );
> > > - if (err < 0) {
> > > + if (err < 0 && err != FDT_ERR_EXISTS) {
> >
> > This FDT_ERR_EXISTS error code is possibly returned by:
> >
> > node = fdt_add_subnode(blob, parent, name);
> > if (node < 0)
> > return node;
> >
> > But if it exists, I believe fdtdec_add_reserved_memory() already
> > returns 0 because they are likely to have the same range of memory
> > block start address and size, no?
> >
>
> Currently, yes. As libfdt and fdtdec_add_reserved_memory external to
> this code, functionality
> can change without modifying fdt_fixup.c knowingly or unknowingly.
> FDT_ERR_EXISTS is harmless error in this context and we shouldn't
> cause boot failure because of that.
> That's why I add that exclusion.
Okay. But the error should be checked against -FDT_ERR_EXISTS.
Regards,
Bin
Re: [linux-sunxi] Re: [RFC PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40
于 2020年6月24日 GMT+08:00 上午8:28:39, "André Przywara" 写到:
>On 19/06/2020 13:16, Icenowy Zheng wrote:
>
>Hi Icenowy,
>
>> Previously we have known that R40 has a configuration register for
>its
>> rank 1, which allows different configuration than rank 0. Reverse
>> engineering of newest libdram of A64 from Allwinner shows that A64
>has
>> this register too. It's bit 0 (which enables dual rank in rank 0
>> configuration register) means a dedicated rank size setup is used for
>> rank 1.
>
>Ah! That's a nice discovery, as it probably explains how my Eachlink H6
>TV box works with its asymmetric 3GB DRAM config!
Wait. The configuration of H6 DRAM controller is totally different. it uses
ADDRMAP registers in DRAM controller, instead of specifying parameters
in MCTL_COM part.
>
>> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
>> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
>> DRAM support necessary.
>>
>> Add this support. As we have gained knowledge of asymmetric dual
>rank,
>> we can now allow R40 dual rank memory setup to work too.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> Testing on R40 boards and A64 single rank boards (e.g. the original
>Pine
>> A64+) is welcomed. I have these boards, but I get too lazy to take
>them
>> out and test them.
>
>I briefly tested this on a Bananapi M2 Berry (R40, 1GB), Pine64 512MB
>and Pine64+ 2GB. All three boot happily into U-Boot, tested the Pine64+
>to the Linux prompt as well.
>
>I will do a proper review shortly.
>
>Thanks for the patch!
>
>Cheers,
>Andre
>
>>
>> .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +-
>> arch/arm/mach-sunxi/dram_sunxi_dw.c | 100
>+-
>> 2 files changed, 84 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>> index a5a7ebde44..e843c14202 100644
>> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
>> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
>> #define NR_OF_BYTE_LANES(32 / BITS_PER_BYTE)
>> /* The eight data lines (DQn) plus DM, DQS and DQSN */
>> #define LINES_PER_BYTE_LANE (BITS_PER_BYTE + 3)
>> -struct dram_para {
>> +
>> +struct rank_para {
>> u16 page_size;
>> -u8 bus_full_width;
>> -u8 dual_rank;
>> u8 row_bits;
>> u8 bank_bits;
>> +};
>> +
>> +struct dram_para {
>> +u8 dual_rank;
>> +u8 bus_full_width;
>> +struct rank_para ranks[2];
>> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>> const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
>> const u8 ac_delays[31];
>> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> index a462538521..7a40d92349 100644
>> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> @@ -349,18 +349,24 @@ static void mctl_set_cr(uint16_t socid, struct
>dram_para *para)
>> #else
>> #error Unsupported DRAM type!
>> #endif
>> - (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>MCTL_CR_FOUR_BANKS) |
>> + (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>MCTL_CR_FOUR_BANKS) |
>> MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK)
>|
>> - MCTL_CR_PAGE_SIZE(para->page_size) |
>> - MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
>> + MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
>> + MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
>>
>> -if (socid == SOCID_R40) {
>> -if (para->dual_rank)
>> -panic("Dual rank memory not supported\n");
>> +if (socid == SOCID_A64 || socid == SOCID_R40) {
>> +writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
>MCTL_CR_FOUR_BANKS) |
>> + MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>> + (para->dual_rank ? MCTL_CR_DUAL_RANK :
>> MCTL_CR_SINGLE_RANK)
>|
>> + MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
>> + MCTL_CR_ROW_BITS(para->ranks[1].row_bits),
>_com->cr_r1);
>> +}
>>
>> +if (socid == SOCID_R40) {
>> /* Mux pin to A15 address line for single rank memory. */
>> -setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
>> +if (!para->dual_rank)
>> +setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
>> }
>> }
>>
>> @@ -584,35 +590,63 @@ static int mctl_channel_init(uint16_t socid,
>struct dram_para *para)
>> return 0;
>> }
>>
>> -static void mctl_auto_detect_dram_size(uint16_t socid, struct
>dram_para *para)
>> +/*
>> + * Test if memory at offset offset matches memory at a certain base
>> + */
>> +static bool mctl_mem_matches_base(u32 offset, ulong base)
>> +{
>> +/* Try to write different values to RAM at two addresses
Re: [RFC PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40
On 19/06/2020 13:16, Icenowy Zheng wrote:
Hi Icenowy,
> Previously we have known that R40 has a configuration register for its
> rank 1, which allows different configuration than rank 0. Reverse
> engineering of newest libdram of A64 from Allwinner shows that A64 has
> this register too. It's bit 0 (which enables dual rank in rank 0
> configuration register) means a dedicated rank size setup is used for
> rank 1.
Ah! That's a nice discovery, as it probably explains how my Eachlink H6
TV box works with its asymmetric 3GB DRAM config!
> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
> DRAM support necessary.
>
> Add this support. As we have gained knowledge of asymmetric dual rank,
> we can now allow R40 dual rank memory setup to work too.
>
> Signed-off-by: Icenowy Zheng
> ---
> Testing on R40 boards and A64 single rank boards (e.g. the original Pine
> A64+) is welcomed. I have these boards, but I get too lazy to take them
> out and test them.
I briefly tested this on a Bananapi M2 Berry (R40, 1GB), Pine64 512MB
and Pine64+ 2GB. All three boot happily into U-Boot, tested the Pine64+
to the Linux prompt as well.
I will do a proper review shortly.
Thanks for the patch!
Cheers,
Andre
>
> .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +-
> arch/arm/mach-sunxi/dram_sunxi_dw.c | 100 +-
> 2 files changed, 84 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> index a5a7ebde44..e843c14202 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
> #define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
> /* The eight data lines (DQn) plus DM, DQS and DQSN */
> #define LINES_PER_BYTE_LANE (BITS_PER_BYTE + 3)
> -struct dram_para {
> +
> +struct rank_para {
> u16 page_size;
> - u8 bus_full_width;
> - u8 dual_rank;
> u8 row_bits;
> u8 bank_bits;
> +};
> +
> +struct dram_para {
> + u8 dual_rank;
> + u8 bus_full_width;
> + struct rank_para ranks[2];
> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> const u8 ac_delays[31];
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index a462538521..7a40d92349 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -349,18 +349,24 @@ static void mctl_set_cr(uint16_t socid, struct
> dram_para *para)
> #else
> #error Unsupported DRAM type!
> #endif
> -(para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> +(para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
> -MCTL_CR_PAGE_SIZE(para->page_size) |
> -MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
> +MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
>
> - if (socid == SOCID_R40) {
> - if (para->dual_rank)
> - panic("Dual rank memory not supported\n");
> + if (socid == SOCID_A64 || socid == SOCID_R40) {
> + writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> +MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> +(para->dual_rank ? MCTL_CR_DUAL_RANK :
> MCTL_CR_SINGLE_RANK) |
> +MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[1].row_bits),
> _com->cr_r1);
> + }
>
> + if (socid == SOCID_R40) {
> /* Mux pin to A15 address line for single rank memory. */
> - setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> + if (!para->dual_rank)
> + setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> }
> }
>
> @@ -584,35 +590,63 @@ static int mctl_channel_init(uint16_t socid, struct
> dram_para *para)
> return 0;
> }
>
> -static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para
> *para)
> +/*
> + * Test if memory at offset offset matches memory at a certain base
> + */
> +static bool mctl_mem_matches_base(u32 offset, ulong base)
> +{
> + /* Try to write different values to RAM at two addresses */
> + writel(0, base);
> + writel(0xaa55aa55, base + offset);
> + dsb();
> + /* Check if the same value is actually observed when reading back */
> + return readl(base) ==
> +readl(base + offset);
> +}
> +
> +static void mctl_auto_detect_dram_size_rank(uint16_t
[PATCH v3] fs/fat/fat.c: Do not perform zero block reads if there are no blocks left
While using u-boot with qemu's virtio driver I stumbled across a
problem reading files less than sector size. On the real hardware the
block reader seems ok with reading zero blocks, and while we could fix
the virtio host side of qemu to deal with a zero block read instead of
crashing, the u-boot fat driver should not be doing zero block reads
in the first place. If you ask hardware to read zero blocks you are
just going to get zero data. There may also be other hardware that
responds similarly to the virtio interface so this is worth fixing.
Without the patch I get the following and have to restart qemu because
it dies.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
qemu-system-aarch64: virtio: zero sized buffers are not allowed
-
With the patch I get the expected results.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
30 bytes read in 11 ms (2 KiB/s)
=> md.b ${loadaddr} 0x1E
4008: 64 77 63 5f 6f 74 67 2e 6c 70 6d 5f 65 6e 61 62dwc_otg.lpm_enab
40080010: 6c 65 3d 30 20 72 6f 6f 74 77 61 69 74 0a le=0 rootwait.
-
Signed-off-by: Jason Wessel
Signed-off-by: Jason Wessel
---
fs/fat/fat.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fd29470c1..dfad1e910b 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -278,7 +278,10 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
} else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect, idx, buffer);
+ if (idx == 0)
+ ret = 0;
+ else
+ ret = disk_read(startsect, idx, buffer);
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.17.1
Re: [External] Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
On Tue, Jun 23, 2020 at 4:33 PM Luca Ceresoli wrote: > > Hi, > > On 23/06/20 23:23, Luca Ceresoli wrote: > > Hi Brandon, > > > > On 23/06/20 19:08, Brandon Maier wrote: > >> On Tue, Jun 23, 2020 at 10:18 AM Luca Ceresoli > >> wrote: > >>> > >> I'm trying to get it to work with Buildroot. Buildroot does have a > >> package for uboot-tools, so I could use that to run it. I'd have to > >> move the config and build commands into Buildroot's uboot package. > >> Since the script belongs to U-Boot anyway, it seemed cleaner to > >> integrate it directly into U-Boot so it could be used by other build > >> systems too. > > > > I understand. But I also understand Michal's concern: the U-Boot > > makefiles are quite complex already, and this feature is a relatively > > minor improvement. > > > > Probably having the conversion in Buildroot could be even simpler as you > > can support _only_ the C format there and do the conversion > > unconditionally. Only one workflow, no ifs, simpler code. Don't forget > > to Cc: me if you send a patch for that, I'll be glad to review it. Either U-Boot or Buildroot is fine by me. If Yocto alreads does it in their U-Boot package then I can see that being a precedent for patching Buildroot. I'll drop this patch to U-Boot then. > > I almost forgot: I wrote some notes on how this could be implemented in > yocto a while back. The principles are pretty much the same so you might > be interested in reading them: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yoctoproject.org_pipermail_meta-2Dxilinx_2019-2DNovember_004578.html=DwICaQ=ilBQI1lupc9Y65XwNblLtw=bIwUnEkCqKFQQ0RVQaaY0gBWY7SIAhmiWLyMS82_mSU=RYp4WeqFQ03XpIUkriybKoxAFXTNGqdNLAgzp4S2S8k=MswLT0A5A80afFFIfBit21JLH37rUpN4gBC_ACxPw6k= > Thanks! > > -- > Luca
Multi DTB selection in SPL FIT image
Hi, I'm trying to implement multi DTB selection via SPL FIT image in iMX8QXP MEK and it is not working. I have the DTB selection code in board_fit_config_name_match but it doesn't even get to this call, if fails on fit_find_config_node: fit_find_config_node: Cannot find /configurations node: -1 Everything seems fine with the generated u-boot-spl.multidtb.fit file but the code cannot find the configurations node. I've also tried LZO and GZIP compression and the results were the same. Final SPL image size is small enough so it won't overwrite BSS. Changes in imx8qxp_mek_defconfig: CONFIG_FIT=y CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="fsl-imx8qxp-mek fsl-imx8qxp-mek-1" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y Are there any suggestions on what can be happening here? Thanks! Vanessa
Fwd: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Forgot to CC -- Forwarded message - From: Brandon Maier Date: Tue, Jun 23, 2020 at 12:16 PM Subject: Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c To: Michal Simek On Tue, Jun 23, 2020 at 11:11 AM Michal Simek wrote: > On 22. 06. 20 22:45, Brandon Maier wrote: > > Add a config to set the file format, but leave the default as binary > > type for backwards compatibility. > > > Based on description I can't see the reason for it. > pmu config object should be aligned with pmu not with u-boot itself. What I mean is, for example if there is a bug in zynqmp_pm_cfg_obj_convert then the pm_cfg binary will automatically be updated the next time U-Boot is built. Compared to if the pm_cfg_obj.bin is stored separately and has to be independently updated for a bug. But it's a minor issue and not that important. > > Also using this script is just one way how to get pmufw config object. > I personally don't use it but I can't see any issue to be in u-boot > project if others want to use it. > We've been trying to piece together the scripts to build pmu config from an HDF using Luca's blog posts and other source code. Out of curiosity, what are these other methods? > > Thanks, > Michal
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Hi, On 23/06/20 23:23, Luca Ceresoli wrote: > Hi Brandon, > > On 23/06/20 19:08, Brandon Maier wrote: >> On Tue, Jun 23, 2020 at 10:18 AM Luca Ceresoli wrote: >>> >>> Hi Brandon, >>> >>> On 22/06/20 22:45, Brandon Maier wrote: To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file back to U-Boot during build. Instead, by doing the conversion in U-Boot during the build, we can simplify the developer's build system. And it ensures that if zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in sync with U-Boot. >>> >>> In the workflows I have used so far U-Boot tools are extracted in a >>> different step w.r.t. U-Boot cross-compilation, so I never felt the need >>> for this feature. But I understand this feature can be handy. >> >> I'm trying to get it to work with Buildroot. Buildroot does have a >> package for uboot-tools, so I could use that to run it. I'd have to >> move the config and build commands into Buildroot's uboot package. >> Since the script belongs to U-Boot anyway, it seemed cleaner to >> integrate it directly into U-Boot so it could be used by other build >> systems too. > > I understand. But I also understand Michal's concern: the U-Boot > makefiles are quite complex already, and this feature is a relatively > minor improvement. > > Probably having the conversion in Buildroot could be even simpler as you > can support _only_ the C format there and do the conversion > unconditionally. Only one workflow, no ifs, simpler code. Don't forget > to Cc: me if you send a patch for that, I'll be glad to review it. I almost forgot: I wrote some notes on how this could be implemented in yocto a while back. The principles are pretty much the same so you might be interested in reading them: https://www.yoctoproject.org/pipermail/meta-xilinx/2019-November/004578.html -- Luca
Fwd: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Forwarding as I forgot to CC -- Forwarded message - From: Brandon Maier Date: Tue, Jun 23, 2020 at 12:08 PM Subject: Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c To: Luca Ceresoli On Tue, Jun 23, 2020 at 10:18 AM Luca Ceresoli wrote: > > Hi Brandon, > > On 22/06/20 22:45, Brandon Maier wrote: > > To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the > > U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert > > their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file > > back to U-Boot during build. > > > > Instead, by doing the conversion in U-Boot during the build, we can > > simplify the developer's build system. And it ensures that if > > zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in > > sync with U-Boot. > > In the workflows I have used so far U-Boot tools are extracted in a > different step w.r.t. U-Boot cross-compilation, so I never felt the need > for this feature. But I understand this feature can be handy. I'm trying to get it to work with Buildroot. Buildroot does have a package for uboot-tools, so I could use that to run it. I'd have to move the config and build commands into Buildroot's uboot package. Since the script belongs to U-Boot anyway, it seemed cleaner to integrate it directly into U-Boot so it could be used by other build systems too. > > The code looks OK too. > > Reviewed-by: Luca Ceresoli > > -- > Luca
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Hi Brandon, On 23/06/20 19:08, Brandon Maier wrote: > On Tue, Jun 23, 2020 at 10:18 AM Luca Ceresoli wrote: >> >> Hi Brandon, >> >> On 22/06/20 22:45, Brandon Maier wrote: >>> To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the >>> U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert >>> their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file >>> back to U-Boot during build. >>> >>> Instead, by doing the conversion in U-Boot during the build, we can >>> simplify the developer's build system. And it ensures that if >>> zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in >>> sync with U-Boot. >> >> In the workflows I have used so far U-Boot tools are extracted in a >> different step w.r.t. U-Boot cross-compilation, so I never felt the need >> for this feature. But I understand this feature can be handy. > > I'm trying to get it to work with Buildroot. Buildroot does have a > package for uboot-tools, so I could use that to run it. I'd have to > move the config and build commands into Buildroot's uboot package. > Since the script belongs to U-Boot anyway, it seemed cleaner to > integrate it directly into U-Boot so it could be used by other build > systems too. I understand. But I also understand Michal's concern: the U-Boot makefiles are quite complex already, and this feature is a relatively minor improvement. Probably having the conversion in Buildroot could be even simpler as you can support _only_ the C format there and do the conversion unconditionally. Only one workflow, no ifs, simpler code. Don't forget to Cc: me if you send a patch for that, I'll be glad to review it. -- Luca
[PATCH v1 4/6] colibri-imx6ull: show boot logo
From: Igor Opaniuk
1. Show boot logo embed in U-Boot blob.
2. Drop iomux configration for LCD, and use the one provided in device
tree.
Signed-off-by: Igor Opaniuk
---
board/toradex/colibri-imx6ull/colibri-imx6ull.c | 40 +
1 file changed, 7 insertions(+), 33 deletions(-)
diff --git a/board/toradex/colibri-imx6ull/colibri-imx6ull.c
b/board/toradex/colibri-imx6ull/colibri-imx6ull.c
index c67d02f..8a34872 100644
--- a/board/toradex/colibri-imx6ull/colibri-imx6ull.c
+++ b/board/toradex/colibri-imx6ull/colibri-imx6ull.c
@@ -57,32 +57,7 @@ static void setup_gpmi_nand(void)
}
#endif /* CONFIG_NAND_MXS */
-#ifdef CONFIG_VIDEO_MXS
-static iomux_v3_cfg_t const lcd_pads[] = {
- MX6_PAD_LCD_CLK__LCDIF_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_ENABLE__LCDIF_ENABLE| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_HSYNC__LCDIF_HSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_CLK__LCDIF_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA00__LCDIF_DATA00| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA01__LCDIF_DATA01| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA02__LCDIF_DATA02| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA03__LCDIF_DATA03| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA04__LCDIF_DATA04| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA05__LCDIF_DATA05| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA06__LCDIF_DATA06| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA07__LCDIF_DATA07| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA08__LCDIF_DATA08| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA09__LCDIF_DATA09| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA10__LCDIF_DATA10| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA11__LCDIF_DATA11| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA12__LCDIF_DATA12| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA13__LCDIF_DATA13| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA14__LCDIF_DATA14| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA15__LCDIF_DATA15| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA16__LCDIF_DATA16| MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX6_PAD_LCD_DATA17__LCDIF_DATA17| MUX_PAD_CTRL(LCD_PAD_CTRL),
-};
-
+#ifdef CONFIG_DM_VIDEO
static iomux_v3_cfg_t const backlight_pads[] = {
/* Backlight On */
MX6_PAD_JTAG_TMS__GPIO1_IO11| MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -95,8 +70,6 @@ static iomux_v3_cfg_t const backlight_pads[] = {
static int setup_lcd(void)
{
- imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
-
imx_iomux_v3_setup_multiple_pads(backlight_pads,
ARRAY_SIZE(backlight_pads));
/* Set BL_ON */
@@ -153,11 +126,6 @@ int board_init(void)
#ifdef CONFIG_NAND_MXS
setup_gpmi_nand();
#endif
-
-#ifdef CONFIG_VIDEO_MXS
- setup_lcd();
-#endif
-
return 0;
}
@@ -203,6 +171,12 @@ int board_late_init(void)
}
#endif /* CONFIG_CMD_USB_SDP */
+#if defined(CONFIG_DM_VIDEO)
+ setup_lcd();
+
+ show_boot_logo();
+#endif
+
return 0;
}
--
2.7.4
[PATCH v1 5/6] colibri-imx6ull: fix splash screen logo drawing
From: Igor Opaniuk Configure white on black for video console. Signed-off-by: Igor Opaniuk --- configs/colibri-imx6ull_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/colibri-imx6ull_defconfig b/configs/colibri-imx6ull_defconfig index 74a67a0..34ab8d6 100644 --- a/configs/colibri-imx6ull_defconfig +++ b/configs/colibri-imx6ull_defconfig @@ -88,3 +88,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_FDT_FIXUP_PARTITIONS=y +CONFIG_SYS_WHITE_ON_BLACK=y -- 2.7.4
[PATCH v1 6/6] colibri-imx7: fix splash logo drawing
From: Igor Opaniuk
1. Configure white on black for video console.
2. Enable printing bmp logo during late board init stage.
3. Use iomux configuration from device tree.
Signed-off-by: Igor Opaniuk
---
board/toradex/colibri_imx7/colibri_imx7.c | 44 +--
configs/colibri_imx7_defconfig| 2 ++
configs/colibri_imx7_emmc_defconfig | 2 ++
3 files changed, 16 insertions(+), 32 deletions(-)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
b/board/toradex/colibri_imx7/colibri_imx7.c
index 8df925d..f585260 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -100,32 +100,7 @@ static void setup_gpmi_nand(void)
}
#endif
-#ifdef CONFIG_VIDEO_MXS
-static iomux_v3_cfg_t const lcd_pads[] = {
- MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_ENABLE__LCD_ENABLE | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_HSYNC__LCD_HSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_VSYNC__LCD_VSYNC | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA00__LCD_DATA0 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA01__LCD_DATA1 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA02__LCD_DATA2 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA03__LCD_DATA3 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA04__LCD_DATA4 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA05__LCD_DATA5 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA06__LCD_DATA6 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA07__LCD_DATA7 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA08__LCD_DATA8 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA09__LCD_DATA9 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA10__LCD_DATA10 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA11__LCD_DATA11 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA12__LCD_DATA12 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA13__LCD_DATA13 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA14__LCD_DATA14 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA15__LCD_DATA15 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA16__LCD_DATA16 | MUX_PAD_CTRL(LCD_PAD_CTRL),
- MX7D_PAD_LCD_DATA17__LCD_DATA17 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-};
-
+#ifdef CONFIG_DM_VIDEO
static iomux_v3_cfg_t const backlight_pads[] = {
/* Backlight On */
MX7D_PAD_SD1_WP__GPIO5_IO1 | MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -139,8 +114,6 @@ static iomux_v3_cfg_t const backlight_pads[] = {
static int setup_lcd(void)
{
- imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
-
imx_iomux_v3_setup_multiple_pads(backlight_pads,
ARRAY_SIZE(backlight_pads));
/* Set BL_ON */
@@ -215,10 +188,6 @@ int board_init(void)
setup_gpmi_nand();
#endif
-#ifdef CONFIG_VIDEO_MXS
- setup_lcd();
-#endif
-
#ifdef CONFIG_USB_EHCI_MX7
imx_iomux_v3_setup_multiple_pads(usb_cdet_pads,
ARRAY_SIZE(usb_cdet_pads));
gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
@@ -382,4 +351,15 @@ int board_usb_phy_mode(int port)
return USB_INIT_HOST;
}
}
+
+int board_late_init(void)
+{
+#if defined(CONFIG_DM_VIDEO)
+ setup_lcd();
+
+ show_boot_logo();
+#endif
+ return 0;
+}
+
#endif
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 7596478..aa6e240 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -87,3 +87,5 @@ CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_DM_VIDEO=y
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_FDT_FIXUP_PARTITIONS=y
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_SYS_WHITE_ON_BLACK=y
diff --git a/configs/colibri_imx7_emmc_defconfig
b/configs/colibri_imx7_emmc_defconfig
index c23ff97..a5aa35f 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -82,3 +82,5 @@ CONFIG_CI_UDC=y
CONFIG_DM_VIDEO=y
CONFIG_FAT_WRITE=y
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_SYS_WHITE_ON_BLACK=y
--
2.7.4
[PATCH v1 3/6] ARM: dts: imx7-colibri: multiple node updates
From: Igor Opaniuk
1. Move u-boot specific nodes to u-boot dts include: legacy lcdif
node and aliases.
2. Add iomux configuration for LCD.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx7-colibri-emmc.dts | 9 +
arch/arm/dts/imx7-colibri-rawnand.dts | 5 +--
arch/arm/dts/imx7-colibri-u-boot.dtsi | 48 +
arch/arm/dts/imx7-colibri.dtsi | 65 +-
board/toradex/colibri_imx7/MAINTAINERS | 1 +
5 files changed, 83 insertions(+), 45 deletions(-)
create mode 100644 arch/arm/dts/imx7-colibri-u-boot.dtsi
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
b/arch/arm/dts/imx7-colibri-emmc.dts
index bc0d10c..dda542a 100644
--- a/arch/arm/dts/imx7-colibri-emmc.dts
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -5,19 +5,12 @@
/dts-v1/;
#include "imx7-colibri.dtsi"
+#include "imx7-colibri-u-boot.dtsi"
/ {
model = "Toradex Colibri iMX7D 1GB (eMMC)";
compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
- aliases {
- u-boot,dm-pre-reloc;
- mmc0 =
- mmc1 =
- display1 =
- usb0 = /* required for ums */
- };
-
chosen {
stdout-path =
};
diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
b/arch/arm/dts/imx7-colibri-rawnand.dts
index 5f12a2a..5241044 100644
--- a/arch/arm/dts/imx7-colibri-rawnand.dts
+++ b/arch/arm/dts/imx7-colibri-rawnand.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include "imx7-colibri.dtsi"
+#include "imx7-colibri-u-boot.dtsi"
/ {
model = "Toradex Colibri iMX7S/D";
@@ -14,10 +15,6 @@
stdout-path =
};
- aliases {
- usb0 = /* required for ums */
- };
-
reg_5v0: regulator-5v0 {
compatible = "regulator-fixed";
regulator-name = "5V";
diff --git a/arch/arm/dts/imx7-colibri-u-boot.dtsi
b/arch/arm/dts/imx7-colibri-u-boot.dtsi
new file mode 100644
index 000..b1a89f0
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-u-boot.dtsi
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright 2020 Toradex
+ */
+/{
+ aliases {
+ mmc0 =
+ mmc1 =
+ display1 =
+ usb0 = /* required for ums */
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_lcdif_dat
+_lcdif_ctrl>;
+ display = <>;
+ u-boot,dm-pre-reloc;
+
+ display0: display0 {
+ bits-per-pixel = <18>;
+ bus-width = <18>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <_vga>;
+ timing_vga: 640x480 {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ vback-porch = <31>;
+ vfront-porch = <11>;
+ hsync-len = <96>;
+ vsync-len = <2>;
+
+ de-active = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri.dtsi b/arch/arm/dts/imx7-colibri.dtsi
index ec95f22..b352036 100644
--- a/arch/arm/dts/imx7-colibri.dtsi
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -172,6 +172,38 @@
>;
};
+ pinctrl_lcdif_dat: lcdif-dat-grp {
+ fsl,pins = <
+ MX7D_PAD_LCD_DATA00__LCD_DATA0 0x79
+ MX7D_PAD_LCD_DATA01__LCD_DATA1 0x79
+ MX7D_PAD_LCD_DATA02__LCD_DATA2 0x79
+ MX7D_PAD_LCD_DATA03__LCD_DATA3 0x79
+ MX7D_PAD_LCD_DATA04__LCD_DATA4 0x79
+ MX7D_PAD_LCD_DATA05__LCD_DATA5 0x79
+ MX7D_PAD_LCD_DATA06__LCD_DATA6 0x79
+ MX7D_PAD_LCD_DATA07__LCD_DATA7 0x79
+ MX7D_PAD_LCD_DATA08__LCD_DATA8 0x79
+ MX7D_PAD_LCD_DATA09__LCD_DATA9 0x79
+ MX7D_PAD_LCD_DATA10__LCD_DATA10 0x79
+ MX7D_PAD_LCD_DATA11__LCD_DATA11 0x79
+ MX7D_PAD_LCD_DATA12__LCD_DATA12 0x79
+ MX7D_PAD_LCD_DATA13__LCD_DATA13 0x79
+ MX7D_PAD_LCD_DATA14__LCD_DATA14 0x79
+ MX7D_PAD_LCD_DATA15__LCD_DATA15 0x79
+
[PATCH v1 2/6] toradex: common: show boot logo
From: Igor Opaniuk
Add function for showing boot logo, embed into u-boot blob.
Signed-off-by: Igor Opaniuk
---
board/toradex/common/tdx-common.c | 26 ++
board/toradex/common/tdx-common.h | 4
2 files changed, 30 insertions(+)
diff --git a/board/toradex/common/tdx-common.c
b/board/toradex/common/tdx-common.c
index e8de923..9b6c8f9 100644
--- a/board/toradex/common/tdx-common.c
+++ b/board/toradex/common/tdx-common.c
@@ -9,6 +9,13 @@
#include
#include
+#ifdef CONFIG_DM_VIDEO
+#include
+#include
+#include
+#include
+#endif
+
#include "tdx-cfg-block.h"
#include
#include "tdx-common.h"
@@ -168,3 +175,22 @@ int ft_common_board_setup(void *blob, bd_t *bd)
}
#endif /* CONFIG_TDX_CFG_BLOCK */
+
+#if defined(CONFIG_DM_VIDEO)
+int show_boot_logo(void)
+{
+ struct udevice *dev;
+ int ret;
+ int xpos, ypos;
+
+ splash_get_pos(, );
+
+ ret = uclass_get_device(UCLASS_VIDEO, 0, );
+ if (ret)
+ return ret;
+
+ ret = video_bmp_display(dev, (ulong)bmp_logo_bitmap, xpos, ypos, true);
+
+ return ret;
+}
+#endif /* CONFIG_DM_VIDEO */
diff --git a/board/toradex/common/tdx-common.h
b/board/toradex/common/tdx-common.h
index c537dca..63614c8 100644
--- a/board/toradex/common/tdx-common.h
+++ b/board/toradex/common/tdx-common.h
@@ -11,4 +11,8 @@
int ft_common_board_setup(void *blob, bd_t *bd);
+#if defined(CONFIG_DM_VIDEO)
+int show_boot_logo(void);
+#endif
+
#endif /* _TDX_COMMON_H */
--
2.7.4
[PATCH v1 1/6] ARM: dts: imx6ull-colibri: move u-boot specific node
From: Igor Opaniuk
Move aliases and legacy lcdif node to the u-boot specific dts include.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 45
arch/arm/dts/imx6ull-colibri.dtsi| 43 --
2 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
index 531cdcc..9b66dda 100644
--- a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
+++ b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
@@ -3,6 +3,15 @@
* Copyright 2019 Toradex AG
*/
+/ {
+ aliases {
+ u-boot,dm-pre-reloc;
+ mmc0 =
+ usb0 = /* required for ums */
+ display0 =
+ };
+};
+
_uart1 {
u-boot,dm-pre-reloc;
};
@@ -10,3 +19,39 @@
_uart1_ctrl1 {
u-boot,dm-pre-reloc;
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lcdif_dat
+_lcdif_ctrl>;
+ status = "okay";
+ display = <>;
+ u-boot,dm-pre-reloc;
+
+ display0: display0 {
+ bits-per-pixel = <18>;
+ bus-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <_vga>;
+ timing_vga: 640x480 {
+ u-boot,dm-pre-reloc;
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ hsync-len = <96>;
+ vsync-len = <2>;
+
+ de-active = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/dts/imx6ull-colibri.dtsi
b/arch/arm/dts/imx6ull-colibri.dtsi
index fca5311..b7bf79f 100644
--- a/arch/arm/dts/imx6ull-colibri.dtsi
+++ b/arch/arm/dts/imx6ull-colibri.dtsi
@@ -8,13 +8,6 @@
#include "imx6ull.dtsi"
/ {
- aliases {
- u-boot,dm-pre-reloc;
- mmc0 =
- usb0 = /* required for ums */
- display0 =
- };
-
chosen {
stdout-path =
};
@@ -151,42 +144,6 @@
};
};
- {
- pinctrl-names = "default";
- pinctrl-0 = <_lcdif_dat
-_lcdif_ctrl>;
- status = "okay";
- display = <>;
- u-boot,dm-pre-reloc;
-
- display0: display0 {
- bits-per-pixel = <18>;
- bus-width = <24>;
- status = "okay";
-
- display-timings {
- native-mode = <_vga>;
- timing_vga: 640x480 {
- u-boot,dm-pre-reloc;
- clock-frequency = <25175000>;
- hactive = <640>;
- vactive = <480>;
- hback-porch = <48>;
- hfront-porch = <16>;
- vback-porch = <33>;
- vfront-porch = <10>;
- hsync-len = <96>;
- vsync-len = <2>;
-
- de-active = <1>;
- hsync-active = <0>;
- vsync-active = <0>;
- pixelclk-active = <0>;
- };
- };
- };
-};
-
/* PWM */
{
pinctrl-names = "default";
--
2.7.4
Re: [RESEND PATCH v5 4/4] test: env: add test for env info sub-command
On 6/23/20 7:25 AM, Patrick DELAUNAY wrote:
> Hi Stephen,
>
>> From: Stephen Warren
>> Sent: lundi 22 juin 2020 20:51
>>
>> On 6/19/20 6:03 AM, Patrick Delaunay wrote:
>>> Add a pytest for testing the env info sub-command:
>>>
>>> test_env_info: test command with several option that can be executed
>>> on real hardware device without assumption
>>>
>>> test_env_info_sandbox: test the result on sandbox with a known ENV
>>> configuration: ready & default & persistent
>>>
>>> The quiet option '-q' is used for support in shell test; for example:
>>> if env info -p -d -q; then env save; fi
>>
>> Acked-by: Stephen Warren
>
> Thanks
>
>
>>> +def test_env_info(state_test_env):
>> ...
>>> +for l in response.split('\n'):
>>> +if 'env_valid = ' in l:
>>> +assert '= invalid' in l or '= valid' in l or '= redundant' in l
>>> +nb_line += 1
>>> +elif 'env_ready =' in l or 'env_use_default =' in l:
>>> +assert '= true' in l or '= false' in l
>>> +nb_line += 1
>>> +else:
>>> +assert true
>>
>> Those last two lines don't seem terribly useful:-)
>
> Not really,
> beacuse I add the nb_line check,
> this first check can be removed.
>
> Do expect a V6 just for that?
Probably not.
Re: [PATCH] travis-ci: Update QEMU RISC-V run command
On 6/23/20 6:34 AM, Bin Meng wrote: > From: Bin Meng > > Explicitly pass the "-bios" option to QEMU to run U-Boot, instead > of the "-kernel" option, as we know that "-bios" behavior will be > changed since QEMU 5.1.0. Applied, thanks.
Re: [PATCH] travis-ci: Update QEMU RISC-V run command
On 6/23/20 7:24 AM, Bin Meng wrote: > Hi Tom, > > On Tue, Jun 23, 2020 at 9:17 PM Tom Rini wrote: >> >> On Tue, Jun 23, 2020 at 05:34:34AM -0700, Bin Meng wrote: >> >>> From: Bin Meng >>> >>> Explicitly pass the "-bios" option to QEMU to run U-Boot, instead >>> of the "-kernel" option, as we know that "-bios" behavior will be >>> changed since QEMU 5.1.0. >>> >>> Signed-off-by: Bin Meng >>> Signed-off-by: Bin Meng >>> --- >>> >>> bin/travis-ci/conf.qemu-riscv32_na | 2 +- >>> bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +- >>> bin/travis-ci/conf.qemu-riscv64_na | 2 +- >>> bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +- >>> 4 files changed, 4 insertions(+), 4 deletions(-) >> >> Note that "travis-ci" is really the wrong subject here, it should be >> "u-boot-test-hooks" or something so it's more clear to Stephen that it's >> for him to pick up and not me :) Thanks! >> > > I believe the tag was local to u-boot-test-hooks as I see the same tag > was used in various commits in u-boot-test-hooks repo. Maybe we should > set up a separate ML for u-boot-test-hooks? I don't think the patch volume is large enough to warrant a whole separate email list. So long as patches are sent to/cc me I'll see them without issue.
Re: [PATCH v2 03/14] dtoc: add support to scan drivers
Hi Simon, On 23/6/20 09:28, Simon Glass wrote: Hi Walter, On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: Currently dtoc scans dtbs to convert them to struct platdata and to generate U_BOOT_DEVICE entries. These entries need to be filled with the driver name, but at this moment the information used is the compatible name present in the dtb. This causes that only nodes with a compatible name that matches a driver name generate a working entry. In order to improve this behaviour, this patch adds to dtoc the capability of scan drivers source code to generate a list of valid driver names. This allows to rise a warning in the case that an U_BOOT_DEVICE entry will try to use a name not valid. Additionally, in order to add more flexibility to the solution, adds the U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an easy way to declare driver name aliases. Thanks to this, dtoc can look for the driver name based on its alias when it populates the U_BOOT_DEVICE entry. Signed-off-by: Walter Lozano --- drivers/clk/at91/pmc.c| 2 + drivers/gpio/mxs_gpio.c | 2 + drivers/gpio/sandbox.c| 2 + drivers/i2c/rk_i2c.c | 2 + drivers/mmc/mxsmmc.c | 1 + drivers/mmc/rockchip_dw_mmc.c | 3 + drivers/mtd/spi/sf_probe.c| 2 + drivers/pinctrl/nxp/pinctrl-mxs.c | 2 + drivers/pinctrl/pinctrl-at91.c| 2 + drivers/power/pmic/rk8xx.c| 2 + drivers/serial/ns16550.c | 4 ++ drivers/spi/mxs_spi.c | 2 + drivers/spi/rk_spi.c | 2 + include/dm/device.h | 7 +++ tools/dtoc/dtb_platdata.py| 89 +-- tools/dtoc/dtoc_test_driver_alias.dts | 20 ++ tools/dtoc/test_dtoc.py | 33 ++ 17 files changed, 173 insertions(+), 4 deletions(-) create mode 100644 tools/dtoc/dtoc_test_driver_alias.dts Reviewed-by: Simon Glass But please can you split out the changes to drivers and device.h into a separate, earlier patch? I'd like to keep tools changes separate where possible. Sure, thanks for your suggestion. Regards, Walter
Re: [PATCH v2 12/14] arm: dts: include gpio nodes for card detect
Hi Simon, On 23/6/20 09:28, Simon Glass wrote: On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: Several MMC drivers use GPIO for card detection with cd-gpios property in the MMC node pointing to a GPIO node. However, as U-Boot tries to save space by keeping only required nodes using u-boot* properties, several devices tree result in having only in the MMC node but not the GPIO node associated to cd-gpios. This patch, fixes several ocurrence of this issue. Signed-off-by: Walter Lozano --- arch/arm/dts/da850-evm-u-boot.dtsi| 4 arch/arm/dts/da850-lcdk-u-boot.dtsi | 4 arch/arm/dts/rk3288-u-boot.dtsi | 4 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 2 +- arch/arm/dts/rk3288-veyron-u-boot.dtsi| 11 +++ 5 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/rk3288-veyron-u-boot.dtsi This patch did not go out to maintainers. If you are using patman, it should do this automatically. Reviewed-by: Simon Glass Thanks again. It is a good point to start using patman, I will do. Regards, Walter
Re: [PATCH v2 08/14] dtoc: extend dtoc to use struct driver_info when linking nodes
Hi Simon, On 23/6/20 09:28, Simon Glass wrote: On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: In the current implementation, when dtoc parses a dtb to generate a struct platdata it converts the information related to linked nodes as pointers to struct platdata of destination nodes. By doing this, it makes difficult to get pointer to udevices created based on these information. This patch extends dtoc to use struct driver_info when populating information about linked nodes, which makes it easier to later get the devices created. In this context, reimplement functions like clk_get_by_index_platdata() which made use of the previous approach. Signed-off-by: Walter Lozano --- drivers/clk/clk-uclass.c| 11 +-- drivers/misc/irq-uclass.c | 10 -- drivers/mmc/ftsdc010_mci.c | 2 +- drivers/mmc/rockchip_dw_mmc.c | 2 +- drivers/mmc/rockchip_sdhci.c| 2 +- drivers/ram/rockchip/sdram_rk3399.c | 2 +- drivers/spi/rk_spi.c| 2 +- include/clk.h | 4 ++-- tools/dtoc/dtb_platdata.py | 24 +--- 9 files changed, 37 insertions(+), 22 deletions(-) Reviewed-by: Simon Glass But I think you need to squash something else in here, or make another changes, as 'make qcheck' fails on this commit. You are right, I will squash the patch which updates the tests. Regards, Walter
Re: [PATCH v2 00/14] improve OF_PLATDATA support
On 23/6/20 11:00, Simon Glass wrote: Hi Walter, On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: When using OF_PLATDATA dtbs are converted to C structs in order to save space as we can remove both dtbs and libraries from TPL/SPL binaries. This patchset tries to improve its support by overcoming some limitations in the current implementation First, the support for scan and check for valid driver/aliases is added in order to generate U_BOOT_DEVICE entries with valid driver names. Secondly, the way information about linked noded (phandle) is generated in C structs is improved in order to make it easier to get a device associated to its data. Lastly the support for the property cd-gpios is added, which is used to configure the card detection gpio on MMC is added. This implementation is based in discussion in [1], [2] and [3] [1] https://patchwork.ozlabs.org/patch/1249198/ [2] https://patchwork.ozlabs.org/project/uboot/list/?series=167495=* [3] https://patchwork.ozlabs.org/project/uboot/list/?series=176759=* Walter Lozano (14): drivers: rename drivers to match compatible string dtoc: add missing code comments dtoc: add support to scan drivers dtoc: add option to disable warnings dm: doc: update of-plat with the support for driver aliases core: drop const for struct driver_info core: extend struct driver_info to point to device dtoc: extend dtoc to use struct driver_info when linking nodes dm: doc: update of-plat with new phandle support dtoc: update tests to match new platdata sandbox: Move section u_boot_list to make it RW arm: dts: include gpio nodes for card detect dtoc: update dtb_platdata to support cd-gpios dtoc add test for cd-gpios One quick point - can you please check the line lengths in the Python code? It looks like some of the lines are over 80cols. That's OK if you are trying to avoid skipping a string which is the first parameter, but otherwise, it should be possible to avoid it. Sure. I thought checkpatch.pl would warn me, but it looks it didn't. Thanks for pointing the issue. Regards, Walter
Re: [PATCH 1/3] riscv: Do not return error if reserved node already exists
On Tue, Jun 23, 2020 at 12:24 AM Bin Meng wrote:
>
> Hi Atish,
>
> On Fri, Jun 19, 2020 at 9:52 AM Atish Patra wrote:
> >
> > Not all errors are fatal. If a reserved memory node already exists in the
> > destination device tree, we can continue to boot without failing.
> >
> > Signed-off-by: Atish Patra
> > ---
> > arch/riscv/lib/fdt_fixup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> > index 6db48ad04a56..91524d9a5ae9 100644
> > --- a/arch/riscv/lib/fdt_fixup.c
> > +++ b/arch/riscv/lib/fdt_fixup.c
> > @@ -62,7 +62,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void
> > *dst)
> > pmp_mem.end = addr + size - 1;
> > err = fdtdec_add_reserved_memory(dst, basename, _mem,
> > );
> > - if (err < 0) {
> > + if (err < 0 && err != FDT_ERR_EXISTS) {
>
> This FDT_ERR_EXISTS error code is possibly returned by:
>
> node = fdt_add_subnode(blob, parent, name);
> if (node < 0)
> return node;
>
> But if it exists, I believe fdtdec_add_reserved_memory() already
> returns 0 because they are likely to have the same range of memory
> block start address and size, no?
>
Currently, yes. As libfdt and fdtdec_add_reserved_memory external to
this code, functionality
can change without modifying fdt_fixup.c knowingly or unknowingly.
FDT_ERR_EXISTS is harmless error in this context and we shouldn't
cause boot failure because of that.
That's why I add that exclusion.
> > printf("failed to add reserved memory: %d\n", err);
> > return err;
> > }
> > --
>
> Regards,
> Bin
--
Regards,
Atish
Re: [PATCH] [RFC] tools: fitmount: fuse mount fit images
On Tue, Jun 23, 2020 at 06:01:38PM +0530, selvamuthukumar v wrote: > On Mon, Jun 15, 2020 at 11:15 PM Selva Muthukumar > wrote: > > > > Allow mounting of FIT images. If FIT images are used for firmware upgrade > > from linux, mouting can save space in comparison to using dumpimage. > > > > Any comments on this? Is there any other way to get FIT image > contents, without extracting it? Sorry for the delay. For your program, there's a few things such as missing license header and being able to opt-in as otherwise we add a new build dependency for everyone. For getting FIT image contents, the existing dumpimage tool handles this. What is missing and would be greatly appreciated is updating some documentation to include what's described in: commit 39931f966adaeadd66dc7a905f7dddb93f66bac3 Author: Guilherme Maciel Ferreira Date: Thu Jan 15 02:54:42 2015 -0200 dumpimage: fit: extract FIT images to be much more visible. What's documented there works today but I had to double check how myself as it's not as visible as it should be. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: qemu-riscv: Update QEMU run command
On Tue, Jun 23, 2020 at 5:25 AM Bin Meng wrote: > > From: Bin Meng > > Explicitly pass the "-bios" option to QEMU to run U-Boot, instead > of the "-kernel" option, as we know that "-bios" behavior will be > changed since QEMU 5.1.0. > > This also updates validated QEMU version to 5.0.0. > > Signed-off-by: Bin Meng > --- > > doc/board/emulation/qemu-riscv.rst | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/doc/board/emulation/qemu-riscv.rst > b/doc/board/emulation/qemu-riscv.rst > index c390006..b68db95 100644 > --- a/doc/board/emulation/qemu-riscv.rst > +++ b/doc/board/emulation/qemu-riscv.rst > @@ -40,11 +40,11 @@ The minimal QEMU command line to get U-Boot up and > running is: > > - For 32-bit RISC-V:: > > -qemu-system-riscv32 -nographic -machine virt -kernel u-boot > +qemu-system-riscv32 -nographic -machine virt -bios u-boot > > - For 64-bit RISC-V:: > > -qemu-system-riscv64 -nographic -machine virt -kernel u-boot > +qemu-system-riscv64 -nographic -machine virt -bios u-boot > > The commands above create targets with 128MiB memory by default. > A freely configurable amount of RAM can be created via the '-m' > @@ -56,7 +56,7 @@ For instructions on how to run U-Boot in supervisor mode on > QEMU > with OpenSBI, see the documentation available with OpenSBI: > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md > > -These have been tested in QEMU 4.2.0. > +These have been tested in QEMU 5.0.0. > > Running U-Boot SPL > -- > @@ -98,10 +98,10 @@ configurations are: > > - For 32-bit RISC-V:: > > -qemu-system-riscv32 -nographic -machine virt -kernel spl/u-boot-spl \ > +qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \ > -device loader,file=u-boot.itb,addr=0x8020 > > - For 64-bit RISC-V:: > > -qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \ > +qemu-system-riscv64 -nographic -machine virt -bios spl/u-boot-spl \ > -device loader,file=u-boot.itb,addr=0x8020 > -- > 2.7.4 > Reviewed-by: Atish Patra -- Regards, Atish
RE: [PATCH v2 6/9] test: environment in ext4
Hi,
> From: Stephen Warren
> Sent: lundi 22 juin 2020 20:57
>
> On 6/16/20 1:40 AM, Patrick Delaunay wrote:
> > Add basic test to persistent environment in ext4:
> > save and load in host ext4 file 'uboot.env'.
> >
> > On first execution an empty EXT4 file system is created in persistent
> > data dir: env.ext4.img.
>
> > diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
>
> > +def mk_env_ext4(state_test_env):
>
> > +if os.path.exists(persistent):
> > +c.log.action('Disk image file ' + persistent + ' already exists')
> > +else:
> > +try:
> > +check_call('rm -f %s' % persistent, shell=True)
>
> This should be run with the results logged to the overall test log file so
> that if there
> are failures, it's possible to see what they were. Use
> util.run_and_log() for this.
Ok, I will modifiy this part (I copy ext4 file create is copied form
py/tests/test_fs/conftest.py:166 mk_fs() )
> Also, this particular command doesn't seem useful, since 4 lines above the
> code
> verified that the file doesn't exist.
Yes not needed, I remove this line.
> > +@pytest.mark.boardspec('sandbox')
> > +@pytest.mark.buildconfigspec('cmd_nvedit_info')
> > +@pytest.mark.buildconfigspec('cmd_echo')
> > +@pytest.mark.buildconfigspec('env_is_in_ext4')
> > +def test_env_ext4(state_test_env):
> > +
> > +c = state_test_env.u_boot_console
>
> Nit: That blank line is a bit odd.
OK
> > +fs_img = mk_env_ext4(state_test_env)
> > +c.run_command('host bind 0 %s' % fs_img)
> > +
> > +response = c.run_command('ext4ls host 0:0')
> > +assert 'uboot.env' not in response
> > +
> > +""" env location: ENVL_EXT4 (2)
> > +"""
>
> Nit: Wrap the trailing """ onto the same line; no need to force it to be a
> multi-line
> string. Also a comman may be better rather than a docstring. Same for the
> other
> docstring later.
OK, I don't realized that it was docstring.
> > +call('rm -f %s' % fs_img, shell=True)
>
> This won't happen if the test fails earlier. Should there be a try/except
> block or
> wrapper function with exception handling to resolve this?
Yes, I add it for V3
Patrick
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
On 22. 06. 20 22:45, Brandon Maier wrote: > To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the > U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert > their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file > back to U-Boot during build. > > Instead, by doing the conversion in U-Boot during the build, we can > simplify the developer's build system. And it ensures that if > zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in > sync with U-Boot. > > Add a config to set the file format, but leave the default as binary > type for backwards compatibility. Based on description I can't see the reason for it. pmu config object should be aligned with pmu not with u-boot itself. Also using this script is just one way how to get pmufw config object. I personally don't use it but I can't see any issue to be in u-boot project if others want to use it. Thanks, Michal
Re: [PATCH] [RFC] tools: fitmount: fuse mount fit images
On Mon, Jun 15, 2020 at 11:15 PM Selva Muthukumar wrote: > > Allow mounting of FIT images. If FIT images are used for firmware upgrade > from linux, mouting can save space in comparison to using dumpimage. > Any comments on this? Is there any other way to get FIT image contents, without extracting it? Thanks, Selva
Pass disk context to GRUB
Hello, I'm trying to enable UEFI dual-booting on the BeagleBone black. U-Boot knows to boot from SD if present, and eMMC if not. However, U-Boot doesn't pass the disk "context" to GRUB; GRUB always thinks it's booting from `hd0`, and doesn't know what to use for the kernel's `root` parameter. I checked the UEFI API, and it seems U-Boot passes a handle to the disk that the GRUB EFI loader was loaded from. Is it possible to also pass a value that can be used to determine the kernel's `root` based on if we're booting from SD or eMMC (and in the future, USB)? For more context, see https://github.com/mendersoftware/meta-mender/pull/1010#issuecomment-647172447 . Thank you, Garrett
Re: [PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
Hi Brandon, On 22/06/20 22:45, Brandon Maier wrote: > To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the > U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert > their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file > back to U-Boot during build. > > Instead, by doing the conversion in U-Boot during the build, we can > simplify the developer's build system. And it ensures that if > zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in > sync with U-Boot. In the workflows I have used so far U-Boot tools are extracted in a different step w.r.t. U-Boot cross-compilation, so I never felt the need for this feature. But I understand this feature can be handy. The code looks OK too. Reviewed-by: Luca Ceresoli -- Luca
Re: [PATCH v2 3/9] env: correctly handle result in env_init
On Tue, Jun 23, 2020 at 01:13:55PM +, Patrick DELAUNAY wrote:
> Hi Tom,
>
> > From: Tom Rini
> > Sent: vendredi 19 juin 2020 20:05
> >
> > On Fri, Jun 19, 2020 at 02:14:00PM +, Patrick DELAUNAY wrote:
> > > Hi Tom and Marek,
> > >
> > > > From: Tom Rini
> > > > Sent: jeudi 18 juin 2020 21:16
> > > >
> > > > On Tue, Jun 16, 2020 at 09:40:42AM +0200, Patrick Delaunay wrote:
> > > >
> > > > > Don't return error with ret=-ENOENT when the optional ops
> > > > > drv->init is absent but only if env_driver_lookup doesn't found
> > > > > driver.
> > > > >
> > > > > This patch correct an issue for the code
> > > > > if (!env_init())
> > > > > env_load()
> > > > > When only ext4 is supported (CONFIG_ENV_IS_IN_EXT4), as the
> > > > > backend env/ext4.c doesn't define an ops .init
> > > > >
> > > > > Signed-off-by: Patrick Delaunay
> > > > > ---
> > > > >
> > > > > (no changes since v1)
> > > > >
> > > > > env/env.c | 5 -
> > > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/env/env.c b/env/env.c index dcc25c030b..819c88f729
> > > > > 100644
> > > > > --- a/env/env.c
> > > > > +++ b/env/env.c
> > > > > @@ -295,7 +295,10 @@ int env_init(void)
> > > > > int prio;
> > > > >
> > > > > for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio));
> > > > > prio++) {
> > > > > - if (!drv->init || !(ret = drv->init()))
> > > > > + ret = 0;
> > > > > + if (drv->init)
> > > > > + ret = drv->init();
> > > > > + if (!ret)
> > > > > env_set_inited(drv->location);
> > > > >
> > > > > debug("%s: Environment %s init done (ret=%d)\n",
> > > > > __func__,
> > > >
> > > > I'm adding in Marek here because this reminds me of similar
> > > > questions / concerns I had looking in to his series. At root, I
> > > > think we're not being consistent in each of our env backing
> > > > implementations about where flags such as ENV_VALID are set, and return
> > values / checks of functions.
> > > >
> > > > Just outside of the start of the patch context here, we set ret to
> > > > -ENOENT and just past this, if still -ENOENT we say ENV_VALID and
> > > > point at the default environment.
> > > >
> > > > But, I don't follow the patch commit message here. If we don't have
> > > > drv->init we call env_set_inited(drv->location) but we won't have
> > > > drv->change
> > > > ret to 0, which means that later on down the function we go back to
> > > > default environment.
> > >
> > > The cause of the issue is because the init() ops is optional in "struct
> > env_driver".
> >
> > Right.
> >
> > > When this opt is absent, I assume that the initialization is not
> > > mandatory but this inititialization need to be tagged in
> > > gd->env_has_init with the call of
> > > env_set_inited() function
> >
> > So when drv->init isn't set we are already calling env_set_inited(...).
> > If that's not the case, what's going on?
> >
> > > And the ENV backend is FOUND (don't return -ENOENT)
> > >
> > > else the next call of env_has_inited(drv->location) always failed : in
> > > env_load()
> > >
> > > I see the error in EXT4 env backend,.all the other backend as a
> > > env_init() function
> > >
> > > But some othe backend don't define the .init operation and have the
> > > issue
> > >
> > > eeprom.c:235:U_BOOT_ENV_LOCATION(eeprom) = {
> > > ext4.c:135:U_BOOT_ENV_LOCATION(ext4) = {
> > > fat.c:128:U_BOOT_ENV_LOCATION(fat) = {
> > > mmc.c:393:U_BOOT_ENV_LOCATION(mmc) = {
> > > onenand.c:108:U_BOOT_ENV_LOCATION(onenand) = {
> > > sata.c:117:U_BOOT_ENV_LOCATION(sata) = {
> > > ubi.c:179:U_BOOT_ENV_LOCATION(ubi) = {
> > >
> > > The other don't have issue:
> > >
> > > flash.c:358:U_BOOT_ENV_LOCATION(flash) = {
> > > flash.c:368: .init = env_flash_init,
> > > nand.c:382:U_BOOT_ENV_LOCATION(nand) = {
> > > nand.c:389: .init = env_nand_init,
> > > nowhere.c:30:U_BOOT_ENV_LOCATION(nowhere) = {
> > > nowhere.c:32: .init = env_nowhere_init,
> > > nvram.c:117:U_BOOT_ENV_LOCATION(nvram) = {
> > > nvram.c:122: .init = env_nvram_init,
> > > remote.c:54:U_BOOT_ENV_LOCATION(remote) = {
> > > remote.c:59: .init = env_remote_init,
> > > sf.c:306:U_BOOT_ENV_LOCATION(sf) = {
> > > sf.c:312: .init = env_sf_init,
> >
> > Right, there should be a problem showing up on a ton of locations, not just
> > ext4
> > which is why I'm concerned / confused here. While ext4 isn't as widely
> > used yet
> > as I would expect, FAT/MMC are.
> >
> > > > So isn't this a problem in most environment cases then? Thanks!
> > >
> > > I don't sure which environment configuration can case issue (only one
> > > ENV without drc->init() function) But no issue if at least one
> > > CONFIG_ENV_IS_ is activated with driver implementing init ops
> > >
> > > But I see the issue in SANDBOX when I activate EXT4 only target.
> > > (CONFIG_ENV_IS_IN_EXT4),
Re: [PATCH U-BOOT v2 00/30] fs: btrfs: Re-implement btrfs support using the more widely used extent buffer base code
Hi Qu, when applying whole series, there are several warning spewed by git: trailing whitespaces, new lines at EOF, spaces before tab in indent. It is possible that this is because the code is copypasted from btrfs-progs and this issues come from there. Also patches 26 and 27 have almost same subject line, and one contains a typo (reolve instead of resolve). Sometimes in commit messages you use the work "cross-port", sometimes it is "crossport", sometimes "cross port". I am going to do a bigger test on this series this week, and if the new code works correctly on all tests, I shall resend your patches with some changes to the commit messages, but I will keep you as author of the commits, and I shall add my Reviewed-by. Marek On Tue, 23 Jun 2020 08:50:57 +0800 Qu Wenruo wrote: > Gentle ping? > > Any updates? > Hopes this won't block the incoming new features too long. > > Thanks, > Qu > > On 2020/5/25 下午2:32, Qu Wenruo wrote: > > The branch can be fetched from github: > > https://github.com/adam900710/u-boot/tree/btrfs_rebuild > > > > The current btrfs code in U-boot is using a creative way to read > > on-disk data. > > It's pretty simple, involving the least amount of code, but pretty > > different from btrfs-progs nor kernel, making it pretty hard to sync > > code between different projects. > > > > This big patchset will rework the btrfs support, to use code mostly > > from btrfs-progs, thus all existing btrfs developers will feel at > > home. > > > > During the rework, the following new features are added: > > - More hash algorithm support > > SHA256 and XXHASH support are added. > > BLAKE2 needs more backport, will happen in a separate patchset. > > > > - The ability to read degraded RAID1 > > Although we still only support one device btrfs, the new code base > > can choose from different copies already. > > As long as new device scan interface is provided, multi-device > > support is pretty simple. > > > > - More correct handling of compressed extents with offset > > For compressed extent with offset, we should read the whole > > compressed extent, decompress them, then copy the referred part. > > > > There are some more features incoming, with the new code base it > > would be much easier to implement: > > - Data checksum support > > The check would happen in read_extent_data(), btrfs-progs has the > > needed facility to locate data csum. > > > > - BLAKE2 support > > Need BLAKE2 library cross ported. > > For btrfs it's just several lines of modification. > > > > - Multi-device support along wit degraded RAID support > > We only need an interface to scan one device without opening it. > > The infrastructure is already provided in this patchset. > > > > These new features would be submitted after the patchset get merged, > > since the patchset is already large, I don't want to make it more > > scary. > > > > Although this patchset look horribly large, most of them are code > > copy from btrfs-progs. > > E.g extent-cache.[ch], rbtree-utils.[ch], btrfs_btree.h. > > And ctree.h has over 1000 lines copied just for various accessors. > > > > While for disk-io.[ch] and volumes-io.[ch], they have some small > > modifications to adapt the interface of U-boot. > > E.g. btrfs_device::fd is replace with blkdev_desc and > > disk_partition_t. > > > > The new code for U-boot are related to the following functions: > > - btrfs_readlink() > > - btrfs_lookup_path() > > - btrfs_read_extent_inline() > > - btrfs_read_extent_reg() > > - lookup_data_extent() > > - btrfs_file_read() > > - btrfs_list_subvols() > > > > Thus only the following 5 patches need extra review attention: > > - Patch 0017 > > - Patch 0019 > > - Patch 0023 > > - Patch 0024 > > - Patch 0025~0028 > > > > Changelog: > > v2: > > - Implement btrfs_list_subvols() > > In v1 it's completely removed thus would cause problem if > > btrfsolume command is compiled in. > > > > - Rebased to latest master > > Only minor conflicts due to header changes. > > > > - Allow next_legnth() to return value > BTRFS_NAME_LEN > > > > Qu Wenruo (30): > > fs: btrfs: Sync btrfs_btree.h from kernel > > fs: btrfs: Add More checksum algorithm support to btrfs > > fs: btrfs: Cross-port btrfs_read_dev_super() from btrfs-progs > > fs: btrfs: Cross-port rbtree-utils from btrfs-progs > > fs: btrfs: Cross-port extent-cache.[ch] from btrfs-progs > > fs: btrfs: Cross-port extent-io.[ch] from btrfs-progs > > fs: btrfs: Cross port structure accessor into ctree.h > > fs: btrfs: Cross port volumes.[ch] from btrfs-progs > > fs: btrfs: Crossport read_tree_block() from btrfs-progs > > fs: btrfs: Rename struct btrfs_path to struct __btrfs_path > > fs: btrfs: Rename btrfs_root to __btrfs_root > > fs: btrfs: Cross port struct btrfs_root to ctree.h > > fs: btrfs: Crossport btrfs_search_slot() from btrfs-progs > > fs: btrfs: Crossport btrfs_read_sys_array() and > > btrfs_read_chunk_tree() > > fs: btrfs: Crossport
Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. The firmware itself is
embedded into U-Boot binary.
One possible firmware source is https://github.com/siemens/k3-rti-wdt.
Signed-off-by: Jan Kiszka
---
drivers/watchdog/Kconfig | 20
drivers/watchdog/Makefile | 3 +++
drivers/watchdog/rti_wdt.c | 24
drivers/watchdog/rti_wdt_fw.S | 20
4 files changed, 67 insertions(+)
create mode 100644 drivers/watchdog/rti_wdt_fw.S
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ee99bd2af1..fd6ab9a85b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -162,6 +162,26 @@ config WDT_K3_RTI
Say Y here if you want to include support for the K3 watchdog
timer (RTI module) available in the K3 generation of processors.
+if WDT_K3_RTI
+
+config WDT_K3_RTI_LOAD_FW
+ bool "Load watchdog firmware"
+ depends on REMOTEPROC
+ help
+ Automatically load the specified firmware image into the MCU R5F
+ core 0. On the AM65x, this firmware is supposed to handle the
expiry
+ of the watchdog timer, typically by resetting the system.
+
+config WDT_K3_RTI_FW_FILE
+ string "Watchdog firmware image file"
+ default "k3-rti-wdt.fw"
+ depends on WDT_K3_RTI_LOAD_FW
+ help
+ Firmware image to be embedded into U-Boot and loaded on watchdog
+ start.
+
+endif
+
config WDT_SANDBOX
bool "Enable Watchdog Timer support for Sandbox"
depends on SANDBOX && WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 16bdbf4970..bf58684875 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
+obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+
+$(obj)/rti_wdt_fw.o: $(shell readlink -f
$(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index ebe29c7409..38e82a6b6b 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* Timer register set definition */
#define RTIDWDCTRL 0x90
@@ -37,11 +38,16 @@
#define WDT_PRELOAD_MAX 0xfff
+#define RTI_PROC_ID 0
Can we get the rproc id from DT?
You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.
I'm now probing for the first instance of "ti,am654-r5f" compatible.
That excludes usage for the J721E for now, but that one is fine without
firmware - provided there is way to prevent power-down for RTI watchdog
otherwise...
+
struct rti_wdt_priv {
phys_addr_t regs;
unsigned int clk_khz;
};
+extern const u32 rti_wdt_fw[];
+extern const int rti_wdt_fw_size;
FIT is the preferred way of packing images in U-Boot. Can you try
using it?
How does that work? Some example for me?
If you happen to refer to fs-loader: That does not target OSPI, our
primary use case.
What benefit would that bring? There are other users of this pattern,
e.g. board/xilinx/zynqmp/pm_cfg_obj.S.
The only benefit of an alternative loading mechanism seems to be
handling of larger images from different sources. But that's what I
would tackle via boot scripting and, thus, without this feature. If you
only have a few hundred bytes to embed, like for k3-rti-wdt, you quickly
have a lot of overhead with other approaches.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [GIT PULL] Pull request: u-boot-imx u-boot-imx-20200623
On Tue, Jun 23, 2020 at 10:46:14AM +0200, Stefano Babic wrote: > Hi Tom, > > I hope last i.MX fixes for relese. List is still quite long, but are > pretty just fixes or related to single boards. > > The following changes since commit f5a821459384a8fc1c8d0a44ce50f7f919257fa8: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-sh (2020-06-20 > 18:51:50 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-20200623 > > for you to fetch changes up to 824e6fe0ae0280cabd9df763fbc3bbaca2682b32: > > mx6cuboxi: remove unused code (2020-06-23 00:08:53 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/14] improve OF_PLATDATA support
Hi Walter, On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > When using OF_PLATDATA dtbs are converted to C structs in order to save > space as we can remove both dtbs and libraries from TPL/SPL binaries. > > This patchset tries to improve its support by overcoming some limitations > in the current implementation > > First, the support for scan and check for valid driver/aliases is added > in order to generate U_BOOT_DEVICE entries with valid driver names. > > Secondly, the way information about linked noded (phandle) is generated > in C structs is improved in order to make it easier to get a device > associated to its data. > > Lastly the support for the property cd-gpios is added, which is used to > configure the card detection gpio on MMC is added. > > This implementation is based in discussion in [1], [2] and [3] > > [1] https://patchwork.ozlabs.org/patch/1249198/ > [2] https://patchwork.ozlabs.org/project/uboot/list/?series=167495=* > [3] https://patchwork.ozlabs.org/project/uboot/list/?series=176759=* > > Walter Lozano (14): > drivers: rename drivers to match compatible string > dtoc: add missing code comments > dtoc: add support to scan drivers > dtoc: add option to disable warnings > dm: doc: update of-plat with the support for driver aliases > core: drop const for struct driver_info > core: extend struct driver_info to point to device > dtoc: extend dtoc to use struct driver_info when linking nodes > dm: doc: update of-plat with new phandle support > dtoc: update tests to match new platdata > sandbox: Move section u_boot_list to make it RW > arm: dts: include gpio nodes for card detect > dtoc: update dtb_platdata to support cd-gpios > dtoc add test for cd-gpios > One quick point - can you please check the line lengths in the Python code? It looks like some of the lines are over 80cols. That's OK if you are trying to avoid skipping a string which is the first parameter, but otherwise, it should be possible to avoid it. Regards, Simon
RE: [RESEND PATCH v5 4/4] test: env: add test for env info sub-command
Hi Stephen,
> From: Stephen Warren
> Sent: lundi 22 juin 2020 20:51
>
> On 6/19/20 6:03 AM, Patrick Delaunay wrote:
> > Add a pytest for testing the env info sub-command:
> >
> > test_env_info: test command with several option that can be executed
> > on real hardware device without assumption
> >
> > test_env_info_sandbox: test the result on sandbox with a known ENV
> > configuration: ready & default & persistent
> >
> > The quiet option '-q' is used for support in shell test; for example:
> > if env info -p -d -q; then env save; fi
>
> Acked-by: Stephen Warren
Thanks
> > +def test_env_info(state_test_env):
> ...
> > +for l in response.split('\n'):
> > +if 'env_valid = ' in l:
> > +assert '= invalid' in l or '= valid' in l or '= redundant' in l
> > +nb_line += 1
> > +elif 'env_ready =' in l or 'env_use_default =' in l:
> > +assert '= true' in l or '= false' in l
> > +nb_line += 1
> > +else:
> > +assert true
>
> Those last two lines don't seem terribly useful:-)
Not really,
beacuse I add the nb_line check,
this first check can be removed.
Do expect a V6 just for that?
Patrick
Re: [PATCH] travis-ci: Update QEMU RISC-V run command
Hi Tom, On Tue, Jun 23, 2020 at 9:17 PM Tom Rini wrote: > > On Tue, Jun 23, 2020 at 05:34:34AM -0700, Bin Meng wrote: > > > From: Bin Meng > > > > Explicitly pass the "-bios" option to QEMU to run U-Boot, instead > > of the "-kernel" option, as we know that "-bios" behavior will be > > changed since QEMU 5.1.0. > > > > Signed-off-by: Bin Meng > > Signed-off-by: Bin Meng > > --- > > > > bin/travis-ci/conf.qemu-riscv32_na | 2 +- > > bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +- > > bin/travis-ci/conf.qemu-riscv64_na | 2 +- > > bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +- > > 4 files changed, 4 insertions(+), 4 deletions(-) > > Note that "travis-ci" is really the wrong subject here, it should be > "u-boot-test-hooks" or something so it's more clear to Stephen that it's > for him to pick up and not me :) Thanks! > I believe the tag was local to u-boot-test-hooks as I see the same tag was used in various commits in u-boot-test-hooks repo. Maybe we should set up a separate ML for u-boot-test-hooks? Regards, Bin
Re: [PATCH] travis-ci: Update QEMU RISC-V run command
On Tue, Jun 23, 2020 at 05:34:34AM -0700, Bin Meng wrote: > From: Bin Meng > > Explicitly pass the "-bios" option to QEMU to run U-Boot, instead > of the "-kernel" option, as we know that "-bios" behavior will be > changed since QEMU 5.1.0. > > Signed-off-by: Bin Meng > Signed-off-by: Bin Meng > --- > > bin/travis-ci/conf.qemu-riscv32_na | 2 +- > bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +- > bin/travis-ci/conf.qemu-riscv64_na | 2 +- > bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) Note that "travis-ci" is really the wrong subject here, it should be "u-boot-test-hooks" or something so it's more clear to Stephen that it's for him to pick up and not me :) Thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH v2 3/9] env: correctly handle result in env_init
Hi Tom,
> From: Tom Rini
> Sent: vendredi 19 juin 2020 20:05
>
> On Fri, Jun 19, 2020 at 02:14:00PM +, Patrick DELAUNAY wrote:
> > Hi Tom and Marek,
> >
> > > From: Tom Rini
> > > Sent: jeudi 18 juin 2020 21:16
> > >
> > > On Tue, Jun 16, 2020 at 09:40:42AM +0200, Patrick Delaunay wrote:
> > >
> > > > Don't return error with ret=-ENOENT when the optional ops
> > > > drv->init is absent but only if env_driver_lookup doesn't found driver.
> > > >
> > > > This patch correct an issue for the code
> > > > if (!env_init())
> > > > env_load()
> > > > When only ext4 is supported (CONFIG_ENV_IS_IN_EXT4), as the
> > > > backend env/ext4.c doesn't define an ops .init
> > > >
> > > > Signed-off-by: Patrick Delaunay
> > > > ---
> > > >
> > > > (no changes since v1)
> > > >
> > > > env/env.c | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/env/env.c b/env/env.c index dcc25c030b..819c88f729
> > > > 100644
> > > > --- a/env/env.c
> > > > +++ b/env/env.c
> > > > @@ -295,7 +295,10 @@ int env_init(void)
> > > > int prio;
> > > >
> > > > for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio));
> > > > prio++) {
> > > > - if (!drv->init || !(ret = drv->init()))
> > > > + ret = 0;
> > > > + if (drv->init)
> > > > + ret = drv->init();
> > > > + if (!ret)
> > > > env_set_inited(drv->location);
> > > >
> > > > debug("%s: Environment %s init done (ret=%d)\n",
> > > > __func__,
> > >
> > > I'm adding in Marek here because this reminds me of similar
> > > questions / concerns I had looking in to his series. At root, I
> > > think we're not being consistent in each of our env backing
> > > implementations about where flags such as ENV_VALID are set, and return
> values / checks of functions.
> > >
> > > Just outside of the start of the patch context here, we set ret to
> > > -ENOENT and just past this, if still -ENOENT we say ENV_VALID and
> > > point at the default environment.
> > >
> > > But, I don't follow the patch commit message here. If we don't have
> > > drv->init we call env_set_inited(drv->location) but we won't have
> > > drv->change
> > > ret to 0, which means that later on down the function we go back to
> > > default environment.
> >
> > The cause of the issue is because the init() ops is optional in "struct
> env_driver".
>
> Right.
>
> > When this opt is absent, I assume that the initialization is not
> > mandatory but this inititialization need to be tagged in
> > gd->env_has_init with the call of
> > env_set_inited() function
>
> So when drv->init isn't set we are already calling env_set_inited(...).
> If that's not the case, what's going on?
>
> > And the ENV backend is FOUND (don't return -ENOENT)
> >
> > else the next call of env_has_inited(drv->location) always failed : in
> > env_load()
> >
> > I see the error in EXT4 env backend,.all the other backend as a
> > env_init() function
> >
> > But some othe backend don't define the .init operation and have the
> > issue
> >
> > eeprom.c:235:U_BOOT_ENV_LOCATION(eeprom) = {
> > ext4.c:135:U_BOOT_ENV_LOCATION(ext4) = {
> > fat.c:128:U_BOOT_ENV_LOCATION(fat) = {
> > mmc.c:393:U_BOOT_ENV_LOCATION(mmc) = {
> > onenand.c:108:U_BOOT_ENV_LOCATION(onenand) = {
> > sata.c:117:U_BOOT_ENV_LOCATION(sata) = {
> > ubi.c:179:U_BOOT_ENV_LOCATION(ubi) = {
> >
> > The other don't have issue:
> >
> > flash.c:358:U_BOOT_ENV_LOCATION(flash) = {
> > flash.c:368:.init = env_flash_init,
> > nand.c:382:U_BOOT_ENV_LOCATION(nand) = {
> > nand.c:389: .init = env_nand_init,
> > nowhere.c:30:U_BOOT_ENV_LOCATION(nowhere) = {
> > nowhere.c:32: .init = env_nowhere_init,
> > nvram.c:117:U_BOOT_ENV_LOCATION(nvram) = {
> > nvram.c:122:.init = env_nvram_init,
> > remote.c:54:U_BOOT_ENV_LOCATION(remote) = {
> > remote.c:59:.init = env_remote_init,
> > sf.c:306:U_BOOT_ENV_LOCATION(sf) = {
> > sf.c:312: .init = env_sf_init,
>
> Right, there should be a problem showing up on a ton of locations, not just
> ext4
> which is why I'm concerned / confused here. While ext4 isn't as widely used
> yet
> as I would expect, FAT/MMC are.
>
> > > So isn't this a problem in most environment cases then? Thanks!
> >
> > I don't sure which environment configuration can case issue (only one
> > ENV without drc->init() function) But no issue if at least one
> > CONFIG_ENV_IS_ is activated with driver implementing init ops
> >
> > But I see the issue in SANDBOX when I activate EXT4 only target.
> > (CONFIG_ENV_IS_IN_EXT4), And no more issue when I add
> CONFIG_ENV_IS_NOWHERE.
> >
> > PS: no direct issue if env_init result is not checked
> >but I check this result in the sandbox tests in next patches:
> > if (!env_init())
> > env_load()
> >
> >but anyway inconsistent value of gd->env_has_init
> >
Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. The firmware itself is
embedded into U-Boot binary.
One possible firmware source is https://github.com/siemens/k3-rti-wdt.
Signed-off-by: Jan Kiszka
---
drivers/watchdog/Kconfig | 20
drivers/watchdog/Makefile | 3 +++
drivers/watchdog/rti_wdt.c| 24
drivers/watchdog/rti_wdt_fw.S | 20
4 files changed, 67 insertions(+)
create mode 100644 drivers/watchdog/rti_wdt_fw.S
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ee99bd2af1..fd6ab9a85b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -162,6 +162,26 @@ config WDT_K3_RTI
Say Y here if you want to include support for the K3 watchdog
timer (RTI module) available in the K3 generation of processors.
+if WDT_K3_RTI
+
+config WDT_K3_RTI_LOAD_FW
+ bool "Load watchdog firmware"
+ depends on REMOTEPROC
+ help
+ Automatically load the specified firmware image into the MCU R5F
+ core 0. On the AM65x, this firmware is supposed to handle the expiry
+ of the watchdog timer, typically by resetting the system.
+
+config WDT_K3_RTI_FW_FILE
+ string "Watchdog firmware image file"
+ default "k3-rti-wdt.fw"
+ depends on WDT_K3_RTI_LOAD_FW
+ help
+ Firmware image to be embedded into U-Boot and loaded on watchdog
+ start.
+
+endif
+
config WDT_SANDBOX
bool "Enable Watchdog Timer support for Sandbox"
depends on SANDBOX && WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 16bdbf4970..bf58684875 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
+obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+
+$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index ebe29c7409..38e82a6b6b 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* Timer register set definition */
#define RTIDWDCTRL0x90
@@ -37,11 +38,16 @@
#define WDT_PRELOAD_MAX 0xfff
+#define RTI_PROC_ID 0
Can we get the rproc id from DT?
You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.
+
struct rti_wdt_priv {
phys_addr_t regs;
unsigned int clk_khz;
};
+extern const u32 rti_wdt_fw[];
+extern const int rti_wdt_fw_size;
FIT is the preferred way of packing images in U-Boot. Can you try using it?
How does that work? Some example for me?
What benefit would that bring? There are other users of this pattern,
e.g. board/xilinx/zynqmp/pm_cfg_obj.S.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
[PATCH] travis-ci: Update QEMU RISC-V run command
From: Bin Meng
Explicitly pass the "-bios" option to QEMU to run U-Boot, instead
of the "-kernel" option, as we know that "-bios" behavior will be
changed since QEMU 5.1.0.
Signed-off-by: Bin Meng
Signed-off-by: Bin Meng
---
bin/travis-ci/conf.qemu-riscv32_na | 2 +-
bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
bin/travis-ci/conf.qemu-riscv64_na | 2 +-
bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/bin/travis-ci/conf.qemu-riscv32_na
b/bin/travis-ci/conf.qemu-riscv32_na
index 3eb9880..5aa25e3 100644
--- a/bin/travis-ci/conf.qemu-riscv32_na
+++ b/bin/travis-ci/conf.qemu-riscv32_na
@@ -6,6 +6,6 @@ console_impl=qemu
qemu_machine="virt"
qemu_binary="qemu-system-riscv32"
qemu_extra_args="-m 1G -nographic -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device
virtio-net-device,netdev=net0"
-qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot"
reset_impl=none
flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv32_spl_na
b/bin/travis-ci/conf.qemu-riscv32_spl_na
index 9a76a54..c1419c2 100644
--- a/bin/travis-ci/conf.qemu-riscv32_spl_na
+++ b/bin/travis-ci/conf.qemu-riscv32_spl_na
@@ -6,6 +6,6 @@ console_impl=qemu
qemu_machine="virt"
qemu_binary="qemu-system-riscv32"
qemu_extra_args="-smp 4 -m 1G -nographic -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device
virtio-net-device,netdev=net0"
-qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
reset_impl=none
flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv64_na
b/bin/travis-ci/conf.qemu-riscv64_na
index 65b2096..90ab820 100644
--- a/bin/travis-ci/conf.qemu-riscv64_na
+++ b/bin/travis-ci/conf.qemu-riscv64_na
@@ -6,6 +6,6 @@ console_impl=qemu
qemu_machine="virt"
qemu_binary="qemu-system-riscv64"
qemu_extra_args="-m 1G -nographic -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device
virtio-net-device,netdev=net0"
-qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot"
reset_impl=none
flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv64_spl_na
b/bin/travis-ci/conf.qemu-riscv64_spl_na
index c0b961c..c3d3dac 100644
--- a/bin/travis-ci/conf.qemu-riscv64_spl_na
+++ b/bin/travis-ci/conf.qemu-riscv64_spl_na
@@ -6,6 +6,6 @@ console_impl=qemu
qemu_machine="virt"
qemu_binary="qemu-system-riscv64"
qemu_extra_args="-smp 4 -m 1G -nographic -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device
virtio-net-device,netdev=net0"
-qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
reset_impl=none
flash_impl=none
--
2.7.4
Re: [PATCH v2 04/14] dtoc: add option to disable warnings
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > As dtoc now performs checks for valid driver names, when running dtoc > tests several warnings arise as these tests don't use valid driver > names. > > This patch adds an option to disable those warning, which is only > intended for running tests. > > Signed-off-by: Walter Lozano > --- > tools/dtoc/dtb_platdata.py | 11 +-- > tools/dtoc/dtoc_test_invalid_driver.dts | 15 > tools/dtoc/test_dtoc.py | 91 + > 3 files changed, 84 insertions(+), 33 deletions(-) > create mode 100644 tools/dtoc/dtoc_test_invalid_driver.dts Reviewed-by: Simon Glass
Re: [PATCH v2 07/14] core: extend struct driver_info to point to device
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Currently when creating an U_BOOT_DEVICE entry a struct driver_info > is declared, which contains the data needed to instantiate the device. > However, the actual device is created at runtime and there is no proper > way to get the device based on its struct driver_info. > > This patch extends struct driver_info adding a pointer to udevice which > is populated during the bind process, allowing to generate a set of > functions to get the device based on its struct driver_info. > > Signed-off-by: Walter Lozano > --- > drivers/core/device.c | 26 +++--- > drivers/core/root.c | 4 > include/dm/device.h | 15 +++ > include/dm/platdata.h | 14 ++ > 4 files changed, 56 insertions(+), 3 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 12/14] arm: dts: include gpio nodes for card detect
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Several MMC drivers use GPIO for card detection with cd-gpios property in > the MMC node pointing to a GPIO node. However, as U-Boot tries to save > space by keeping only required nodes using u-boot* properties, several > devices tree result in having only in the MMC node but not the GPIO node > associated to cd-gpios. > > This patch, fixes several ocurrence of this issue. > > Signed-off-by: Walter Lozano > --- > arch/arm/dts/da850-evm-u-boot.dtsi| 4 > arch/arm/dts/da850-lcdk-u-boot.dtsi | 4 > arch/arm/dts/rk3288-u-boot.dtsi | 4 > arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 2 +- > arch/arm/dts/rk3288-veyron-u-boot.dtsi| 11 +++ > 5 files changed, 24 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/rk3288-veyron-u-boot.dtsi This patch did not go out to maintainers. If you are using patman, it should do this automatically. Reviewed-by: Simon Glass
Re: [PATCH v2 11/14] sandbox: Move section u_boot_list to make it RW
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > In order to be able to update data in u_boot_list, move this section to > make it RW. > > Signed-off-by: Walter Lozano > --- > arch/sandbox/cpu/u-boot-spl.lds | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v2 09/14] dm: doc: update of-plat with new phandle support
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Update documentation to reflect the new phandle support when OF_PLATDATA > is used. Now phandles are implemented as pointers to U_BOOT_DEVICE, > which makes it possible to get a pointer to the actual device. > > Signed-off-by: Walter Lozano > --- > doc/driver-model/of-plat.rst | 24 > 1 file changed, 16 insertions(+), 8 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 1/1] cmd: fdt: remove CMD_FDT_MAX_DUMP
On Fri, 19 Jun 2020 at 11:46, Heinrich Schuchardt wrote:
>
> When printing the device tree we want to get an output that can be used as
> input for the device tree compiler. This requires that we do not write
> bogus lines like
>
> pcie@1000 {
> interrupt-map = * 0x4000127c [0x0280];
>
> For instance the QEMU virt device has a property interrupt-map with 640
> bytes which exceeds CMD_FDT_MAX_DUMP=64.
>
> So lets do away with the artificial limitation to 64 bytes.
>
> As indicated in commit f0a29d43313c ("fdt: Limit printed hex in fdt print
> and list commands") if a device tree contains binary blobs, it may still
> be desirable to limit the output length. Provide environment variable
> fdt_max_dump for this purpose.
>
> Fixes: 5d927b428622 ("Kconfig: Drop CONFIG_CMD_FDT_MAX_DUMP")
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/fdt.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
Reviewed-by: Simon Glass
Re: [PATCH v2 14/14] dtoc add test for cd-gpios
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Add a test for dtoc taking into account the cd-gpios property. > > Signed-off-by: Walter Lozano > --- > tools/dtoc/dtoc_test_phandle_cd_gpios.dts | 42 ++ > tools/dtoc/test_dtoc.py | 67 +++ > 2 files changed, 109 insertions(+) > create mode 100644 tools/dtoc/dtoc_test_phandle_cd_gpios.dts Reviewed-by: Simon Glass
Re: [PATCH v2 06/14] core: drop const for struct driver_info
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > In order to prepare for a new support of phandle when OF_PLATDATA is used > drop the const for struct driver_info as this struct will need to be > updated on runtime. > > Signed-off-by: Walter Lozano > --- > drivers/core/device.c| 2 +- > drivers/core/root.c | 2 +- > include/dm/device-internal.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 08/14] dtoc: extend dtoc to use struct driver_info when linking nodes
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > In the current implementation, when dtoc parses a dtb to generate a struct > platdata it converts the information related to linked nodes as pointers > to struct platdata of destination nodes. By doing this, it makes > difficult to get pointer to udevices created based on these > information. > > This patch extends dtoc to use struct driver_info when populating > information about linked nodes, which makes it easier to later get > the devices created. In this context, reimplement functions like > clk_get_by_index_platdata() which made use of the previous approach. > > Signed-off-by: Walter Lozano > --- > drivers/clk/clk-uclass.c| 11 +-- > drivers/misc/irq-uclass.c | 10 -- > drivers/mmc/ftsdc010_mci.c | 2 +- > drivers/mmc/rockchip_dw_mmc.c | 2 +- > drivers/mmc/rockchip_sdhci.c| 2 +- > drivers/ram/rockchip/sdram_rk3399.c | 2 +- > drivers/spi/rk_spi.c| 2 +- > include/clk.h | 4 ++-- > tools/dtoc/dtb_platdata.py | 24 +--- > 9 files changed, 37 insertions(+), 22 deletions(-) Reviewed-by: Simon Glass But I think you need to squash something else in here, or make another changes, as 'make qcheck' fails on this commit.
Re: [PATCH v2 10/14] dtoc: update tests to match new platdata
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > After using a new approach to link nodes when OF_PLATDATA is enabled > the test cases need to be update. > > This patch updates the tests based on this new implementation. > > Signed-off-by: Walter Lozano > --- > tools/dtoc/test_dtoc.py | 103 +++- > 1 file changed, 60 insertions(+), 43 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v2 13/14] dtoc: update dtb_platdata to support cd-gpios
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Currently dtoc does not support the property cd-gpios used to declare > the gpios for card detect in mmc. > > This patch adds support to cd-gpios property. > > Signed-off-by: Walter Lozano > --- > tools/dtoc/dtb_platdata.py | 13 - > tools/dtoc/test_dtoc.py| 2 +- > 2 files changed, 9 insertions(+), 6 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 05/14] dm: doc: update of-plat with the support for driver aliases
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Update the documentation with the support for driver aliases using > U_BOOT_DRIVER_ALIAS. > > Signed-off-by: Walter Lozano > --- > doc/driver-model/of-plat.rst | 14 +- > 1 file changed, 13 insertions(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 02/14] dtoc: add missing code comments
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Add missing information about internal class members in order to make > the code easier to follow. > > Signed-off-by: Walter Lozano > --- > tools/dtoc/dtb_platdata.py | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH v2 01/14] drivers: rename drivers to match compatible string
On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > When using OF_PLATDATA, the bind process between devices and drivers > is performed trying to match compatible string with driver names. > However driver names are not strictly defined, and also there are different > names used when declaring a driver with U_BOOT_DRIVER, the name of the > symbol used in the linker list and the used in the struct driver_info. > > In order to make things a bit more clear, rename the drivers names. This > will also help for further OF_PLATDATA improvements, such as checking > for valid driver names. > > Signed-off-by: Walter Lozano > --- > .../mach-at91/arm926ejs/at91sam9260_devices.c | 6 +-- > .../arm926ejs/at91sam9m10g45_devices.c| 10 ++-- > arch/arm/mach-rockchip/rk3328/syscon_rk3328.c | 4 +- > board/davinci/da8xxevm/omapl138_lcdk.c| 2 +- > board/sandbox/sandbox.c | 2 +- > drivers/clk/at91/clk-master.c | 4 +- > drivers/clk/at91/clk-peripheral.c | 4 +- > drivers/clk/at91/pmc.c| 4 +- > drivers/core/simple-bus.c | 4 +- > drivers/gpio/at91_gpio.c | 4 +- > drivers/gpio/da8xx_gpio.c | 4 +- > drivers/gpio/mxs_gpio.c | 6 +-- > drivers/gpio/rk_gpio.c| 4 +- > drivers/gpio/sandbox.c| 4 +- > drivers/i2c/rk_i2c.c | 4 +- > drivers/input/cros_ec_keyb.c | 4 +- > drivers/misc/cros_ec_sandbox.c| 4 +- > drivers/mmc/davinci_mmc.c | 4 +- > drivers/mmc/mxsmmc.c | 6 +-- > drivers/mmc/rockchip_dw_mmc.c | 2 +- > drivers/mtd/spi/sf-uclass.c | 2 +- > drivers/mtd/spi/sf_probe.c| 4 +- > drivers/pinctrl/nxp/pinctrl-mxs.c | 4 +- > drivers/pinctrl/pinctrl-at91.c| 4 +- > drivers/pinctrl/rockchip/pinctrl-rk3188.c | 2 +- > drivers/pinctrl/rockchip/pinctrl-rk3288.c | 2 +- > drivers/pinctrl/rockchip/pinctrl-rk3328.c | 2 +- > drivers/pinctrl/rockchip/pinctrl-rk3368.c | 2 +- > drivers/power/pmic/rk8xx.c| 4 +- > drivers/power/regulator/fixed.c | 4 +- > drivers/ram/rockchip/dmc-rk3368.c | 2 +- > drivers/ram/rockchip/sdram_rk3188.c | 2 +- > drivers/ram/rockchip/sdram_rk3288.c | 2 +- > drivers/ram/rockchip/sdram_rk3328.c | 2 +- > drivers/serial/sandbox.c | 6 +-- > drivers/spi/mxs_spi.c | 6 +-- > drivers/spi/rk_spi.c | 6 +-- > drivers/spi/sandbox_spi.c | 4 +- > drivers/tpm/tpm_tis_sandbox.c | 4 +- > drivers/video/rockchip/rk3288_vop.c | 4 +- > drivers/video/sandbox_sdl.c | 4 +- > drivers/watchdog/at91sam9_wdt.c | 4 +- > test/dm/gpio.c| 2 +- > test/dm/spi.c | 6 +-- > test/py/tests/test_bind.py| 54 +-- > 45 files changed, 104 insertions(+), 120 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 03/14] dtoc: add support to scan drivers
Hi Walter, On Fri, 19 Jun 2020 at 08:56, Walter Lozano wrote: > > Currently dtoc scans dtbs to convert them to struct platdata and > to generate U_BOOT_DEVICE entries. These entries need to be filled > with the driver name, but at this moment the information used is the > compatible name present in the dtb. This causes that only nodes with > a compatible name that matches a driver name generate a working > entry. > > In order to improve this behaviour, this patch adds to dtoc the > capability of scan drivers source code to generate a list of valid driver > names. This allows to rise a warning in the case that an U_BOOT_DEVICE > entry will try to use a name not valid. > > Additionally, in order to add more flexibility to the solution, adds the > U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an > easy way to declare driver name aliases. Thanks to this, dtoc can look > for the driver name based on its alias when it populates the U_BOOT_DEVICE > entry. > > Signed-off-by: Walter Lozano > --- > drivers/clk/at91/pmc.c| 2 + > drivers/gpio/mxs_gpio.c | 2 + > drivers/gpio/sandbox.c| 2 + > drivers/i2c/rk_i2c.c | 2 + > drivers/mmc/mxsmmc.c | 1 + > drivers/mmc/rockchip_dw_mmc.c | 3 + > drivers/mtd/spi/sf_probe.c| 2 + > drivers/pinctrl/nxp/pinctrl-mxs.c | 2 + > drivers/pinctrl/pinctrl-at91.c| 2 + > drivers/power/pmic/rk8xx.c| 2 + > drivers/serial/ns16550.c | 4 ++ > drivers/spi/mxs_spi.c | 2 + > drivers/spi/rk_spi.c | 2 + > include/dm/device.h | 7 +++ > tools/dtoc/dtb_platdata.py| 89 +-- > tools/dtoc/dtoc_test_driver_alias.dts | 20 ++ > tools/dtoc/test_dtoc.py | 33 ++ > 17 files changed, 173 insertions(+), 4 deletions(-) > create mode 100644 tools/dtoc/dtoc_test_driver_alias.dts > Reviewed-by: Simon Glass But please can you split out the changes to drivers and device.h into a separate, earlier patch? I'd like to keep tools changes separate where possible. Regards, Simon
Re: [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog
On 23.06.20 13:47, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
This is based on the Linux kernel driver for the RTI watchdog.
To actually reset the system on an AM65x, it requires firmware running
on the R5 that accepts the NMI and issues the actual system reset via
TISCI. Kind of an iTCO, except that this watchdog hardware has support
for no-way-out, and only for that.
On the J721E, reset works without extra firmware help when routing the
RTI interrupt via the ESM.
Signed-off-by: Jan Kiszka
---
drivers/watchdog/Kconfig | 7 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/rti_wdt.c | 123 +
3 files changed, 131 insertions(+)
create mode 100644 drivers/watchdog/rti_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index bf06180cdd..ee99bd2af1 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -155,6 +155,13 @@ config WDT_ORION
Select this to enable Orion watchdog timer, which can be found on some
Marvell Armada chips.
+config WDT_K3_RTI
+ bool "Texas Instruments K3 RTI watchdog"
+ depends on WDT && ARCH_K3
+ help
+ Say Y here if you want to include support for the K3 watchdog
+ timer (RTI module) available in the K3 generation of processors.
+
config WDT_SANDBOX
bool "Enable Watchdog Timer support for Sandbox"
depends on SANDBOX && WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 519bbd3a40..16bdbf4970 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
+obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
new file mode 100644
index 00..ebe29c7409
--- /dev/null
+++ b/drivers/watchdog/rti_wdt.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) Siemens AG, 2020
+ *
+ * Authors:
+ * Jan Kiszka
+ *
+ * Derived from linux/drivers/watchdog/rti_wdt.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Timer register set definition */
+#define RTIDWDCTRL 0x90
+#define RTIDWDPRLD 0x94
+#define RTIWDSTATUS0x98
+#define RTIWDKEY 0x9c
+#define RTIDWDCNTR 0xa0
+#define RTIWWDRXCTRL 0xa4
+#define RTIWWDSIZECTRL 0xa8
+
+#define RTIWWDRX_NMI 0xa
+
+#define RTIWWDSIZE_50P 0x50
+
+#define WDENABLE_KEY 0xa98559da
+
+#define WDKEY_SEQ0 0xe51a
+#define WDKEY_SEQ1 0xa35c
+
+#define WDT_PRELOAD_SHIFT 13
+
+#define WDT_PRELOAD_MAX0xfff
+
+struct rti_wdt_priv {
+ phys_addr_t regs;
+ unsigned int clk_khz;
+};
+
+static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ struct rti_wdt_priv *priv = dev_get_priv(dev);
+ u32 timer_margin;
+ int ret;
+
+ if (readl(priv->regs + RTIDWDCTRL) == WDENABLE_KEY)
+ return -EBUSY;
+
+ timer_margin = timeout_ms * priv->clk_khz / 1000;
+ timer_margin >>= WDT_PRELOAD_SHIFT;
+ if (timer_margin > WDT_PRELOAD_MAX)
+ timer_margin = WDT_PRELOAD_MAX;
+
+ writel(timer_margin, priv->regs + RTIDWDPRLD);
+ writel(RTIWWDRX_NMI, priv->regs + RTIWWDRXCTRL);
+ writel(RTIWWDSIZE_50P, priv->regs + RTIWWDSIZECTRL);
+
+ readl(priv->regs + RTIWWDSIZECTRL);
+
+ writel(WDENABLE_KEY, priv->regs + RTIDWDCTRL);
What happens if the watchdog timer expires in U-Boot?
Then we reset. You can feed the watchdog also from U-Boot, just enable
CONFIG_WATCHDOG.
Is the watchdog started from U-Boot command line?
U-Boot automatically starts the first watchdog it finds. I didn't find a
switch to disable that. If you have multiple watchdogs, you can start
others also via "wdt".
+
+ return 0;
+}
+
+static int rti_wdt_reset(struct udevice *dev)
+{
+ struct rti_wdt_priv *priv = dev_get_priv(dev);
+ u32 prld;
+
+ /* Make sure we do not reset too early */
+ prld = readl(priv->regs + RTIDWDPRLD) << WDT_PRELOAD_SHIFT;
+ if (readl(priv->regs + RTIDWDCNTR) >= prld / 2)
+ return -EPERM;
+
+ writel(WDKEY_SEQ0, priv->regs + RTIWDKEY);
+ writel(WDKEY_SEQ1, priv->regs + RTIWDKEY);
+
+ return 0;
+}
+
+static int rti_wdt_probe(struct udevice *dev)
+{
+ struct rti_wdt_priv *priv = dev_get_priv(dev);
+ struct clk clk;
+ int ret;
+
+ priv->regs = devfdt_get_addr(dev);
+ if (!priv->regs)
+ return -EINVAL;
+
+ ret = clk_get_by_index(dev, 0, );
+ if (ret)
+
[PATCH] doc: qemu-riscv: Update QEMU run command
From: Bin Meng Explicitly pass the "-bios" option to QEMU to run U-Boot, instead of the "-kernel" option, as we know that "-bios" behavior will be changed since QEMU 5.1.0. This also updates validated QEMU version to 5.0.0. Signed-off-by: Bin Meng --- doc/board/emulation/qemu-riscv.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index c390006..b68db95 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -40,11 +40,11 @@ The minimal QEMU command line to get U-Boot up and running is: - For 32-bit RISC-V:: -qemu-system-riscv32 -nographic -machine virt -kernel u-boot +qemu-system-riscv32 -nographic -machine virt -bios u-boot - For 64-bit RISC-V:: -qemu-system-riscv64 -nographic -machine virt -kernel u-boot +qemu-system-riscv64 -nographic -machine virt -bios u-boot The commands above create targets with 128MiB memory by default. A freely configurable amount of RAM can be created via the '-m' @@ -56,7 +56,7 @@ For instructions on how to run U-Boot in supervisor mode on QEMU with OpenSBI, see the documentation available with OpenSBI: https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md -These have been tested in QEMU 4.2.0. +These have been tested in QEMU 5.0.0. Running U-Boot SPL -- @@ -98,10 +98,10 @@ configurations are: - For 32-bit RISC-V:: -qemu-system-riscv32 -nographic -machine virt -kernel spl/u-boot-spl \ +qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \ -device loader,file=u-boot.itb,addr=0x8020 - For 64-bit RISC-V:: -qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \ +qemu-system-riscv64 -nographic -machine virt -bios spl/u-boot-spl \ -device loader,file=u-boot.itb,addr=0x8020 -- 2.7.4
Re: [PATCH 1/3] video: add support for drawing 8bpp bitmap on 32bpp framebuffer
Hi Igor, On Tue, 23 Jun 2020 14:40:45 +0300 Igor Opaniuk igor.opan...@gmail.com wrote: ... > Any chance to get this merged? We had a display issue on mx6ul_14x14_evk with these patches applied, I didn't have time to debug this further. From what I remember now, it was not exactly clear if this issue is caused by other mx6ul SoC or driver changes in mainline or if this is the result of the mx6ul DM_VIDEO conversion. Also, there is another patch [1] addressing this drawing problem. I hope to find time later this week to decide which patch should be merged better. [1] http://patchwork.ozlabs.org/project/uboot/patch/1591782743-22846-3-git-send-email-ye...@nxp.com -- Anatolij
RE: [PATCH] ARM: imx: soc: Add reset for non-DM case
> Subject: Re: [PATCH] ARM: imx: soc: Add reset for non-DM case
>
> Hi Everybody,
>
> CC: Igor / Oleksandr from Toradex
>
>
> On 22.05.20 01:14, Marek Vasut wrote:
> > This is another in series of patches which remove ad-hoc reset_cpu()
> > hacks from board files. This one is for iMX7, so implement default
> > reset_cpu() there to prevent it from showing up in board files.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Fabio Estevam
> > Cc: NXP i.MX U-Boot Team
> > Cc: Peng Fan
> > Cc: Stefano Babic
> > ---
> > arch/arm/mach-imx/mx7/soc.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/mx7/soc.c
> b/arch/arm/mach-imx/mx7/soc.c
> > index 798fe74a3d..e7c71dfe8e 100644
> > --- a/arch/arm/mach-imx/mx7/soc.c
> > +++ b/arch/arm/mach-imx/mx7/soc.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -419,3 +420,15 @@ void reset_misc(void) #endif }
> >
> > +#if !CONFIG_IS_ENABLED(SYSRESET)
> > +void reset_cpu(ulong addr)
> > +{
> > + struct watchdog_regs *wdog = (struct watchdog_regs
> > +*)WDOG1_BASE_ADDR;
> > +
> > + /* Clear WDA to trigger WDOG_B immediately */
> > + writew(SET_WCR_WT(1) | WCR_WDT | WCR_WDE | WCR_SRS,
> >wcr);
> > +
> > + while (1)
> > + ;
> > +}
> > +#endif
> >
>
> The patch is in the right direction, but rather this breaks Toradex's colibri
> i.MX7. However, reset should not coded in a board file and boards should
> enable DM PMIC and simply use the provide reset functionalities. Igor /
> Oleksandr, could you take a look at this ?
It might depends on internal warm reset or external pmic reset of the board
choice. And better not enable both, because there might be contention.
Regards,
Peng.
I will let this patch for a while in
> stand-by.
>
> Best regards,
> Stefano
>
> --
> ==
> ===
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> ==
> ===
