Re: [PATCH v13 09/10] arm_ffa: efi: introduce FF-A MM communication
Hi Abdellatif, On Fri, Jun 16, 2023 at 04:28:16PM +0100, Abdellatif El Khlifi wrote: > Add MM communication support using FF-A transport > > This feature allows accessing MM partitions services through > EFI MM communication protocol. MM partitions such as StandAlonneMM > or smm-gateway secure partitions which reside in secure world. > > An MM shared buffer and a door bell event are used to exchange > the data. > > The data is used by EFI services such as GetVariable()/SetVariable() > and copied from the communication buffer to the MM shared buffer. > > The secure partition is notified about availability of data in the > MM shared buffer by an FF-A message (door bell). > > On such event, MM SP can read the data and updates the MM shared > buffer with the response data. > > The response data is copied back to the communication buffer and > consumed by the EFI subsystem. > > MM communication protocol supports FF-A 64-bit direct messaging. > > Signed-off-by: Abdellatif El Khlifi > Signed-off-by: Gowtham Suresh Kumar > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > > --- > > Changelog: > === > > v13: > > * remove FF-A and Optee ifdefs Thanks this looks a lot saner now. I got one last nit and I think this patch is ready > + * Return: > + * > + * 0 on success > + */ > +static int ffa_notify_mm_sp(void) > +{ > + struct ffa_send_direct_data msg = {0}; > + int ret; > + int sp_event_ret = -1; > + struct udevice *dev; > + > + ret = uclass_first_device_err(UCLASS_FFA, &dev); > + if (ret) { > + log_err("EFI: Cannot find FF-A bus device, notify MM SP > failure\n"); > + return ret; > + } > + > + msg.data0 = FFA_SHARED_MM_BUFFER_OFFSET; /* x3 */ > + > + ret = ffa_sync_send_receive(dev, mm_sp_id, &msg, 1); > + if (ret) > + return ret; > + > + sp_event_ret = msg.data0; /* x3 */ > + > + if (sp_event_ret == MM_SUCCESS) > + return 0; > + > + /* Failure to notify the MM SP */ > + > + return -EACCES; Doesn't FFA and the SMM_GATEWAY have discrete returns results that would make more sense? Your other patches only define MM_SUCCESS but in ffa_mm_communicate() you are trying to map ernnos to EFI return codes. I think we should map errnos to ffa errors as well in a similar fashion. You can look at optee_mm_communicate() which already does that. > +} > + > +/** > + * ffa_discover_mm_sp_id() - Query the MM partition ID > + * > +/** > + * get_mm_comms() - detect the available MM transport > + * > + * Make sure the FF-A bus is probed successfully > + * which means FF-A communication with secure world works and ready > + * for use. > + * > + * If FF-A bus is not ready, use OPTEE comms. > + * > + * Return: > + * > + * MM_COMMS_FFA or MM_COMMS_OPTEE > + */ > +static enum mm_comms_select get_mm_comms(void) > +{ > + struct udevice *dev; > + int ret; > + > + ret = uclass_first_device_err(UCLASS_FFA, &dev); > + if (ret) { > + log_err("EFI: Cannot find FF-A bus device, trying Optee > comms\n"); > + return MM_COMMS_OPTEE; > + } > + > + return MM_COMMS_FFA; > +} > + > +/** > + * mm_communicate() - Adjust the communication buffer to the MM SP and send > * it to OP-TEE > * > - * @comm_buf:locally allocted communcation buffer > + * @comm_buf:locally allocated communication buffer > * @dsize: buffer size > + * > + * The SP (also called partition) can be any MM SP such as StandAlonneMM or > smm-gateway. > + * The comm_buf format is the same for both partitions. > + * When using the u-boot OP-TEE driver, StandAlonneMM is supported. > + * When using the u-boot FF-A driver, any MM SP is supported. > + * > * Return: status code > */ > static efi_status_t mm_communicate(u8 *comm_buf, efi_uintn_t dsize) > { > efi_status_t ret; > + enum mm_comms_select mm_comms; > struct efi_mm_communicate_header *mm_hdr; > struct smm_variable_communicate_header *var_hdr; > > @@ -162,7 +400,12 @@ static efi_status_t mm_communicate(u8 *comm_buf, > efi_uintn_t dsize) > mm_hdr = (struct efi_mm_communicate_header *)comm_buf; > var_hdr = (struct smm_variable_communicate_header *)mm_hdr->data; > > - ret = optee_mm_communicate(comm_buf, dsize); > + mm_comms = get_mm_comms(); > + if (mm_comms == MM_COMMS_FFA) > + ret = ffa_mm_communicate(comm_buf, dsize); > + else > + ret = optee_mm_communicate(comm_buf, dsize); > + > if (ret != EFI_SUCCESS) { > log_err("%s failed!\n", __func__); > return ret; > @@ -232,6 +475,7 @@ static u8 *setup_mm_hdr(void **dptr, efi_uintn_t > payload_size, > */ > efi_status_t EFIAPI get_max_payload(efi_uintn_t *size) > { > + enum mm_comms_select mm_comms; > struct smm_variable_payload_size *var_payload = NULL; > efi_uintn_t payload_size; > u8 *comm_buf =
Re: [EXTERNAL] Re: [PATCH 0/2] Mitigate warnings occurred during compilation
Hi Tom, On 19/06/23 18:48, Tom Rini wrote: On Mon, Jun 19, 2023 at 03:14:01PM +0530, Nikhil M Jain wrote: This patch series aims at mitigating warnings occurred during compilation by including required header files and using appropriate types for variables which are typecasted. Nikhil M Jain (2): board: ti: am62x: evm: Include necessary header files common: splash_source: Fix type casting errors. board/ti/am62x/evm.c | 1 + common/splash_source.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) What is this on top of, or what changes have been made to stock defconfigs to make these problems appear? These errors appear when you enable CONFIG_SPLASH_SOURCE and CONFIG_FIT is enabled. Thanks, Nikhil
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > wrote: > > > > > > > > Add a target for building EFI capsules. The capsule parameters are > > > > specified through a config file, and the path to the config file is > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file is > > > > not specified, the command only builds tools. > > > > > > > > Signed-off-by: Sughosh Ganu > > > > --- > > > > Makefile | 9 + > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/Makefile b/Makefile > > > > index 10bfaa52ad..96db29aa77 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > dts/dt.dtb: u-boot > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > + > > > > +PHONY += capsule > > > > +capsule: tools > > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > > > + $(call cmd,mkeficapsule) > > > > +endif > > > > + > > > > quiet_cmd_copy = COPY$@ > > > >cmd_copy = cp $< $@ > > > > > > > > -- > > > > 2.34.1 > > > > > > > > > > We should be using binman to build images...you seem to be building > > > something in parallel with that. Can you please take a look at binman? > > > > Again, I had explored using binman for this task. The one issue where > > I find the above flow better is that I can simply build my payload > > image(s) followed by 'make capsule' to generate the capsules for > > earlier generated images. In it's current form, I don't see an easy > > way to enforce this dependency in binman when I want to build the > > payload followed by generation of capsules. I did see the mention of > > encapsulating an entry within another dependent entry, but I think > > that makes the implementation more complex than it ought to be. > > > > I think it is much easier to use the make flow to generate the images > > followed by capsules, instead of tweaking the binman node to first > > generate the payload images, followed by enabling the capsule node to > > build the capsules. If there is an easy way of enforcing this > > dependency, please let me know. Thanks > > Can you share your explorations? I think the capsule should be created > as part of the build, if enabled. Rather than changing the input > files, binman should produce new output files. This is an issue of handling dependencies in binman, and not changing input files. We do not have support for telling binman "build/generate this particular image first before you proceed to build the capsules using the earlier built images". I am not sure if this can be done in a generic manner in binman, so that irrespective of the image being generated, it can be specified to build capsules once the capsule input images have been generated. > > We are trying to remove most of the output logic in Makefile. It > should just be producing input files for binman. I understand. However, like I mentioned above, as of now, we don't have a way of handling dependencies in binman, at least in a generic manner. Once this support gets added, I know that it would be trivial to add support for building capsules in binman. -sughosh
Re: [PATCH 1/7] capsule: authenticate: Embed capsule public key in platform's dtb
hi Simon, On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 15 Jun 2023 at 17:11, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 13 Jun 2023 at 11:41, Sughosh Ganu > > > wrote: > > > > > > > > The EFI capsule authentication logic in u-boot expects the public key > > > > in the form of an EFI Signature List(ESL) to be provided as part of > > > > the platform's dtb. Currently, the embedding of the ESL file into the > > > > dtb needs to be done manually. > > > > > > > > Add a script for embedding the ESL used for capsule authentication in > > > > the platform's dtb, and call this as part of building the dtb(s). This > > > > brings the embedding of the ESL in the dtb into the u-boot build flow. > > > > > > > > The path to the ESL file is specified through the > > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol. > > > > > > > > Signed-off-by: Sughosh Ganu > > > > --- > > > > lib/efi_loader/Kconfig | 11 +++ > > > > scripts/Makefile.lib | 8 > > > > scripts/embed_capsule_key.sh | 25 + > > > > 3 files changed, 44 insertions(+) > > > > create mode 100755 scripts/embed_capsule_key.sh > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > index c5835e6ef6..1326a1d109 100644 > > > > --- a/lib/efi_loader/Kconfig > > > > +++ b/lib/efi_loader/Kconfig > > > > @@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX > > > > Select the max capsule index value used for capsule report > > > > variables. This value is used to create CapsuleMax variable. > > > > > > > > +config EFI_CAPSULE_ESL_FILE > > > > + string "Path to the EFI Signature List File" > > > > + default "" > > > > + depends on EFI_CAPSULE_AUTHENTICATE > > > > + help > > > > + Provides the absolute path to the EFI Signature List > > > > + file which will be embedded in the platform's device > > > > + tree and used for capsule authentication at the time > > > > + of capsule update. > > > > + > > > > + > > > > config EFI_DEVICE_PATH_TO_TEXT > > > > bool "Device path to text protocol" > > > > default y > > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > > > > index 7b27224b5d..a4083d0a26 100644 > > > > --- a/scripts/Makefile.lib > > > > +++ b/scripts/Makefile.lib > > > > @@ -192,6 +192,8 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp > > > > -nostdinc\ > > > > -D__ASSEMBLY__ > > > > \ > > > > -undef -D__DTS__ > > > > > > > > +export dtc_cpp_flags > > > > + > > > > # Finds the multi-part object the current object will be linked into > > > > modname-multi = $(sort $(foreach m,$(multi-used),\ > > > > $(if $(filter $(subst $(obj)/,,$*.o), $($(m:.o=-objs)) > > > > $($(m:.o=-y))),$(m:.o= > > > > @@ -315,6 +317,9 @@ ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y) > > > > DTC_FLAGS += -@ > > > > endif > > > > > > > > +quiet_cmd_embedcapsulekey = EMBEDCAPSULEKEY $@ > > > > +cmd_embedcapsulekey = $(srctree)/scripts/embed_capsule_key.sh $@ > > > > + > > > > quiet_cmd_dtc = DTC $@ > > > > # Modified for U-Boot > > > > # Bring in any U-Boot-specific include at the end of the file > > > > @@ -333,6 +338,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ > > > > > > > > $(obj)/%.dtb: $(src)/%.dts FORCE > > > > $(call if_changed_dep,dtc) > > > > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y) > > > > + $(call cmd,embedcapsulekey,$@) > > > > +endif > > > > > > > > pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp) > > > > dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) > > > > diff --git a/scripts/embed_capsule_key.sh b/scripts/embed_capsule_key.sh > > > > new file mode 100755 > > > > index 00..1c2e45f758 > > > > --- /dev/null > > > > +++ b/scripts/embed_capsule_key.sh > > > > @@ -0,0 +1,25 @@ > > > > +#! /bin/bash > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > +# > > > > +# Copyright (C) 2023, Linaro Limited > > > > +# > > > > + > > > > +gen_capsule_signature_file() { > > > > +cat >> $1 << EOF > > > > +/dts-v1/; > > > > +/plugin/; > > > > + > > > > +&{/} { > > > > + signature { > > > > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE); > > > > + }; > > > > +}; > > > > +EOF > > > > +} > > > > + > > > > +gen_capsule_signature_file signature.$$.dts > /dev/null 2>&1 > > > > +$CPP $dtc_cpp_flags -x assembler-with-cpp -o signature.$$.tmp > > > > signature.$$.dts > /dev/null 2>&1 > > > > +dtc -@ -O dtb -o signature.$$.dtbo signature.$$.tmp > /dev/null 2>&1 > > > > +fdtoverlay -i $1 -o temp.$$.dtb -v signature.$$.dtbo > /dev/null 2>&1 > > > > +mv temp.$$.dtb $1 > /dev/null 2>&1 > > > > +rm -f signature.$$.* > /dev/null 2>&1 > > > > -- > > > > 2.34.1 > > > > > > > > > > Can you please add this to binman instead? > > > >
Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION
On 6/20/23 22:40, Detlev Casanova wrote: On Tuesday, June 20, 2023 4:03:18 P.M. EDT Marek Vasut wrote: On 6/20/23 19:49, Detlev Casanova wrote: On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote: On 6/19/23 20:27, Detlev Casanova wrote: On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote: On 6/19/23 16:42, Detlev Casanova wrote: On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote: On 6/16/23 17:21, Detlev Casanova wrote: Expose that information to the command shell to let scripts select the correct devicetree name. Signed-off-by: Detlev Casanova --- drivers/sysinfo/rcar3.c | 46 - 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c index 7b127986da7..89ad46c5422 100644 --- a/drivers/sysinfo/rcar3.c +++ b/drivers/sysinfo/rcar3.c @@ -32,6 +32,8 @@ */ struct sysinfo_rcar_priv { char boardmodel[64]; + u8 id; + charrevision[4]; u8 val; }; @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice *dev, int id, size_t size, char *> switch (id) { case SYSINFO_ID_BOARD_MODEL: - strncpy(val, priv->boardmodel, size); - val[size - 1] = '\0'; + strlcpy(val, priv->boardmodel, size); + break; + case SYSINFO_ID_BOARD_REVISION: + strlcpy(val, priv->revision, size); + break; + default: + return -EINVAL; + }; + + val[size - 1] = '\0'; + return 0; +} + +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int *val) +{ + struct sysinfo_rcar_priv *priv = dev_get_priv(dev); + + switch (id) { + case SYSINFO_ID_BOARD_ID: + *val = priv->id; return 0; Why not return SYSINFO_ID_BOARD_REVISION as integer here ? Because the revision (on r-car3 boards at least) is in the format X.Y. It could be returned as "(X << 8) | Y" or split in major/minor. But different boards will use different revisions and I think that having a str is easier to deal with in a shell script. With rcar they are numbers, so lets go with major/minor integers please. Ok for this part, but shouldn't the sysinfo command use a common interface for all boards ? Or should it also have rev_major/rev_minor arguments ? I would expect other boards to either report rev_major/rev_minor if implemented, or errno if those boards don't implement this property. Another thing on rcar is that the revision is stored as 2 char values. Would you oppose a change form using a char (e.g. rev_major = '1') to using u8 values (e.g. rev_major = 1) instead ? Shouldn't those rev fields just be integer(s) to cover the generic case? On rcar, they are chars. I don't really see a reason for this except to show the '?.?' on unknown board ids. But that can be managed in other ways. Yes I know, I am more concerned about other boards which might not have such short revision number, so why not just make the revision fields integer which covers very much anything ? Also, if you have those fields set to integer, then -EINVAL could be printed as '?' .
Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
On 6/21/23 04:55, Chong, Teik Heng wrote: -Original Message- From: Marek Vasut Sent: Wednesday, 21 June, 2023 9:20 AM To: Chong, Teik Heng ; u-boot@lists.denx.de Cc: Jagan Teki ; Vignesh R ; Simon ; Kris ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Zamri, Muhammad Hazim Izzat ; Lim, Jit Loon ; Tang, Sieu Mun ; Patrice CHOTARD ; Patrick DELAUNAY Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register On 6/21/23 02:57, Chong, Teik Heng wrote: -Original Message- From: Marek Vasut Sent: Wednesday, 21 June, 2023 5:38 AM To: Chong, Teik Heng ; u-boot@lists.denx.de Cc: Jagan Teki ; Vignesh R ; Simon ; Kris ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Zamri, Muhammad Hazim Izzat ; Lim, Jit Loon ; Tang, Sieu Mun ; Patrice CHOTARD ; Patrick DELAUNAY Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register On 6/20/23 15:52, teik.heng.ch...@intel.com wrote: From: Teik Heng Chong Fix the write to the HPRT register which treat W1C fields as if they were mere RW. This leads to unintended clearing of such fields Signed-off-by: Teik Heng Chong --- V1->V2 - update subject tags to usb:dwc2 --- drivers/usb/host/dwc2.c | 34 -- drivers/usb/host/dwc2.h | 4 2 files changed, 12 insertions(+), 26 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..9818f9be94 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev, /* Turn on the vbus power. */ if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { - hprt0 = readl(®s->hprt0); - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET); - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG); + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { hprt0 |= DWC2_HPRT0_PRTPWR; writel(hprt0, ®s->hprt0); @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS: switch (wValue) { case USB_PORT_FEAT_C_CONNECTION: - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTCONNDET); break; } break; @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, break; case USB_PORT_FEAT_RESET: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | +DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_POWER: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_ENABLE: @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) dwc_otg_core_host_init(dev, regs); } - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET | -DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG | -DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | +DWC2_HPRT0_PRTRST); for (i = 0; i < MAX_DEVICE; i++) { for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct dw
[PATCH v1 17/17] tools: binman: update binman tool for agilex5
From: Sieu Mun Tang This is for new platform enablement for agilex5. Update binman tool for new platform. Signed-off-by: Sieu Mun Tang --- tools/binman/control.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/binman/control.py b/tools/binman/control.py index 68597c4e77..51e94c9e65 100644 --- a/tools/binman/control.py +++ b/tools/binman/control.py @@ -7,11 +7,11 @@ from collections import OrderedDict import glob -try: -import importlib.resources -except ImportError: +#try: +#import importlib.resources +#except ImportError: # for Python 3.6 -import importlib_resources +#import importlib_resources import os import pkg_resources import re -- 2.26.2
[PATCH v1 12/17] drivers: phy: add combo phy driver for agilex5
This is for new platform enablement for agilex5. Add combo phy driver for new platform. Signed-off-by: Jit Loon Lim --- drivers/phy/cadence/Kconfig| 9 + drivers/phy/cadence/Makefile | 1 + drivers/phy/cadence/phy-cadence-combophy.c | 855 + 3 files changed, 865 insertions(+) create mode 100644 drivers/phy/cadence/phy-cadence-combophy.c diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig index 549ddbf504..61d1b36be2 100644 --- a/drivers/phy/cadence/Kconfig +++ b/drivers/phy/cadence/Kconfig @@ -1,3 +1,12 @@ +config PHY_CADENCE_COMBOPHY + tristate "Cadence ComboPhy PHY Driver" + depends on MMC_SDHCI_CADENCE + help + Enable this to support the Cadence ComboPhy PHY driver + A single module that encapsulates all functionality required to interface + to external NAND Flash, eMMC devices, and SD cards for command and data + transfer. + config PHY_CADENCE_SIERRA tristate "Cadence Sierra PHY Driver" depends on DM_RESET diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile index af63b32d9f..3092b9f3b8 100644 --- a/drivers/phy/cadence/Makefile +++ b/drivers/phy/cadence/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o +obj-$(CONFIG_PHY_CADENCE_COMBOPHY) += phy-cadence-combophy.o diff --git a/drivers/phy/cadence/phy-cadence-combophy.c b/drivers/phy/cadence/phy-cadence-combophy.c new file mode 100644 index 00..c49c45e5a0 --- /dev/null +++ b/drivers/phy/cadence/phy-cadence-combophy.c @@ -0,0 +1,855 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Cadence COMBOPHY PHY Driver + * + * Based on the linux driver provided by Cadence Sierra + * + * Copyright (c) 2022 - 2023 Intel Corporation + * Author: Lee, Kah Jing + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* PHY register offsets */ +/* General define */ +#define BIT_ZERO 0 +#define BIT_ONE1 +#define SD_HOST_CLK 2 + +/* SDIO Card UHS-I modes */ +#define SDIO_MODE_SDR120 +#define SDIO_MODE_SDR251 +#define SDIO_MODE_SDR502 +#define SDIO_MODE_SDR104 3 +#define SDIO_MODE_DDR504 +#define SD_MODE_HS 5 + +/* eMMC modes */ +#define eMMC_MODE_SDR 0 +#define eMMC_MODE_HS 1 +#define eMMC_MODE_HS2002 +#define eMMC_MODE_HS4003 +/* SW_RESET_REG */ +#define SDHCI_CDNS_HRS00 0x00 +#define SDHCI_CDNS_HRS00_SWR BIT(0) +/* PHY access port */ +#define SDHCI_CDNS_HRS04 0x10 +#define SDHCI_CDNS_HRS04_ADDR GENMASK(5, 0) +/* PHY data access port */ +#define SDHCI_CDNS_HRS05 0x14 +/* eMMC control registers */ +#define SDHCI_CDNS_HRS06 0x18 + +#define READ_OP0 +#define WRITE_OP 1 +#define READ_WRITE_OP 2 +#define POLLING_OP 3 +#define READ_PHY_OP4 +#define READ_WRITE_PHY_OP 5 + +#define PHY_TYPE_NAND 0 +#define PHY_TYPE_SDMMC 1 +#define PHY_REG_LEN15 +/* IO_DELAY_INFO_REG */ +#define SDHCI_CDNS_HRS07 0x1c +#define SDHCI_CDNS_HRS07_RW_COMPENSATE GENMASK(20, 16) +#define SDHCI_CDNS_HRS07_IDELAY_VALGENMASK(4, 0) +/* TODO: check DV dfi_init val=9 */ +#define SDHCI_CDNS_HRS07_RW_COMPENSATE_DATA0x9 +/* TODO: check DV dfi_init val=8; DDR Mode */ +#define SDHCI_CDNS_HRS07_RW_COMPENSATE_DATA_DDR0x8 +#define SDHCI_CDNS_HRS07_IDELAY_VAL_DATA 0x0 +/* PHY reset port */ +#define SDHCI_CDNS_HRS09 0x24 +#define SDHCI_CDNS_HRS09_PHY_SW_RESET BIT(0) +#define SDHCI_CDNS_HRS09_PHY_INIT_COMPLETE BIT(1) +#define SDHCI_CDNS_HRS09_EXTENDED_RD_MODE BIT(2) +#define SDHCI_CDNS_HRS09_EXTENDED_WR_MODE BIT(3) +#define SDHCI_CDNS_HRS09_RDCMD_EN BIT(15) +#define SDHCI_CDNS_HRS09_RDDATA_EN BIT(16) + +/* PHY reset port */ +#define SDHCI_CDNS_HRS10 0x28 +#define SDHCI_CDNS_HRS10_HCSDCLKADJGENMASK(19, 16) +#define SDHCI_CDNS_HRS10_HCSDCLKADJ_DATA 0x0 +/* HCSDCLKADJ DATA; DDR Mode */ +#define SDHCI_CDNS_HRS10_HCSDCLKADJ_DATA_DDR 0x2 + +/* CMD_DATA_OUTPUT */ +#define SDHCI_CDNS_HRS16 0x40 +#define SDHCI_CDNS_HRS16_WRDATA1_SDCLK_DLY GENMASK(31, 28) +#define SDHCI_CDNS_HRS16_WRDATA0_SDCLK_DLY GENMASK(27, 24) +#define SDHCI_CDNS_HRS16_WRCMD1_SDCLK_DLY GENMASK(23, 20) +#define SDHCI_CDNS_HRS16_WRCMD0_SDCLK_DLY GENMASK(19, 16) +#define SDHCI_
[PATCH v1 16/17] includes: add and update configuration for agilex5
This is for new platform enablement for agilex5. Add in new configuration that needed to boot new platform. Signed-off-by: Jit Loon Lim --- arch/arm/mach-socfpga/Kconfig | 55 + configs/socfpga_agilex5_defconfig | 2 + configs/socfpga_agilex5_legacy_defconfig | 2 + include/configs/socfpga_agilex5_socdk.h | 12 + include/configs/socfpga_soc64_common.h| 214 +- include/dt-bindings/clock/agilex5-clock.h | 71 ++ include/dt-bindings/reset/altr,rst-mgr-agx5.h | 82 +++ 7 files changed, 428 insertions(+), 10 deletions(-) create mode 100644 include/configs/socfpga_agilex5_socdk.h create mode 100644 include/dt-bindings/clock/agilex5-clock.h create mode 100644 include/dt-bindings/reset/altr,rst-mgr-agx5.h diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 562c3796ec..a35928ef47 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -3,6 +3,10 @@ if ARCH_SOCFPGA config ERR_PTR_OFFSET default 0xfffec000 if TARGET_SOCFPGA_GEN5 # Boot ROM range +config MEM_RESERVE_SECURE + int + default 0 + config NR_DRAM_BANKS default 1 @@ -33,6 +37,37 @@ config SPL_STACK_R_ADDR config SPL_SYS_MALLOC_F_LEN default 0x800 if TARGET_SOCFPGA_GEN5 +config SYS_CACHELINE_SIZE + default 64 + +config SYS_INIT_RAM_ADDR + bool + default 0xFFE0 if TARGET_SOCFPGA_AGILEX + default 0x0 if TARGET_SOCFPGA_AGILEX5 + default 0xFFE0 if TARGET_SOCFPGA_N5X + default 0xFFE0 if TARGET_SOCFPGA_STRATIX10 + +config SYS_INIT_RAM_SIZE + bool + default 0x4 if TARGET_SOCFPGA_AGILEX + default 0x8 if TARGET_SOCFPGA_AGILEX5 + default 0x4 if TARGET_SOCFPGA_N5X + default 0x4 if TARGET_SOCFPGA_STRATIX10 + +config SYS_MAX_NAND_DEVICE + default 1 + +config SYS_NAND_ONFI_DETECTION + default 1 + +config SYS_NAND_U_BOOT_SIZE + int + default 1048576 + +config SYS_NAND_U_BOOT_DST + bool + default CONFIG_TEXT_BASE if TARGET_SOCFPGA_SOC64 + config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE default 0xa2 @@ -40,6 +75,16 @@ config SYS_MALLOC_F_LEN default 0x2000 if TARGET_SOCFPGA_ARRIA10 default 0x2000 if TARGET_SOCFPGA_GEN5 +config SYS_NS16550_MEM32 + default y if TARGET_SOCFPGA_SOC64 + +config SYS_SDRAM_BASE + bool + default 0x0 if TARGET_SOCFPGA_AGILEX + default 0x8000 if TARGET_SOCFPGA_AGILEX5 + default 0x0 if TARGET_SOCFPGA_N5X + default 0x0 if TARGET_SOCFPGA_STRATIX10 + config TEXT_BASE default 0x0140 if TARGET_SOCFPGA_ARRIA10 default 0x0140 if TARGET_SOCFPGA_GEN5 @@ -59,29 +104,35 @@ config TARGET_SOCFPGA_AGILEX select ARMV8_SET_SMPEN select BINMAN if SPL_ATF select CLK + select CONFIG_BOOTFILE if SPL_ATF select FPGA_INTEL_SDM_MAILBOX select GICV2 select NCORE_CACHE select SPL_CLK if SPL + select SYS_SDRAM_BASE select TARGET_SOCFPGA_SOC64 config TARGET_SOCFPGA_AGILEX5 bool select BINMAN if SPL_ATF select CLK + select CONFIG_BOOTFILE if SPL_ATF select FPGA_INTEL_SDM_MAILBOX select GICV3 select NCORE_CACHE select SPL_CLK if SPL + select SYS_SDRAM_BASE select TARGET_SOCFPGA_SOC64 config TARGET_SOCFPGA_AGILEX5_EMU bool "Enable build that bootable only on Agilex5 Emulator" + select TARGET_SOCFPGA_AGILEX5 help This is to use for Agilex5 Emulator. config TARGET_SOCFPGA_AGILEX5_SIMICS bool "Enable build that bootable only on Agilex5 Simics platform" + select TARGET_SOCFPGA_AGILEX5 help This is to use for Agilex5 Simics. @@ -127,10 +178,12 @@ config TARGET_SOCFPGA_N5X select ARMV8_SET_SMPEN select BINMAN if SPL_ATF select CLK + select CONFIG_BOOTFILE if SPL_ATF select FPGA_INTEL_SDM_MAILBOX select NCORE_CACHE select SPL_ALTERA_SDRAM select SPL_CLK if SPL + select SYS_SDRAM_BASE select TARGET_SOCFPGA_SOC64 config TARGET_SOCFPGA_N5X_SOCDK @@ -145,7 +198,9 @@ config TARGET_SOCFPGA_STRATIX10 select ARMV8_MULTIENTRY select ARMV8_SET_SMPEN select BINMAN if SPL_ATF + select CONFIG_BOOTFILE if SPL_ATF select FPGA_INTEL_SDM_MAILBOX + select SYS_SDRAM_BASE select TARGET_SOCFPGA_SOC64 choice diff --git a/configs/socfpga_agilex5_defconfig b/configs/socfpga_agilex5_defconfig index 6a90fa0b27..8e5c7e6f70 100644 --- a/configs/socfpga_agilex5_defconfig +++ b/configs/socfpga_agilex5_defconfig @@ -50,6 +50,8 @@ CONFIG_CMD_FAT=y CONFIG_DOS_PARTITION=y CONFIG_SPL_DOS_PARTITION=y CONFIG_SPL_SYS_DISABLE_DCACHE_OPS=y +CONFIG_USE_BOOTFILE=y +CONFIG_BOOTFILE="kernel.itb" CONFIG_CMD_MTD=y CONFIG_CMD_NAND_TRIMFFS=y CONFIG_CMD_NAND_LOCK_UNLOC
[PATCH v1 15/17] drivers: watchdog: update watchdog driver for agilex5
This is for new platform enablement for agilex5. Update watchdog timeout timer for new platform. Signed-off-by: Jit Loon Lim --- drivers/watchdog/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 646663528a..18d2e33e09 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -28,7 +28,7 @@ config WATCHDOG_TIMEOUT_MSECS int "Watchdog timeout in msec" default 128000 if ARCH_MX31 || ARCH_MX5 || ARCH_MX6 default 128000 if ARCH_MX7 || ARCH_VF610 - default 3 if ARCH_SOCFPGA + default 1 if ARCH_SOCFPGA default 16000 if ARCH_SUNXI default 5376 if ULP_WATCHDOG default 15000 if ARCH_BCM283X -- 2.26.2
[PATCH v1 14/17] drivers: sysreset: add system driver for agilex5
This is for new platform enablement for agilex5. Add cold, warm reset logic for new platform. Signed-off-by: Jit Loon Lim --- drivers/sysreset/Kconfig| 7 drivers/sysreset/Makefile | 1 + drivers/sysreset/sysreset_socfpga_agilex5.c | 44 + 3 files changed, 52 insertions(+) create mode 100644 drivers/sysreset/sysreset_socfpga_agilex5.c diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig index 03f7fdd597..850191eeed 100644 --- a/drivers/sysreset/Kconfig +++ b/drivers/sysreset/Kconfig @@ -137,6 +137,13 @@ config SYSRESET_SOCFPGA_SOC64 This enables the system reset driver support for Intel SOCFPGA SoC64 SoCs. +config SYSRESET_SOCFPGA_AGILEX5 + bool "Enable support for Intel SOCFPGA AGILEX5 device" + depends on ARCH_SOCFPGA && TARGET_SOCFPGA_AGILEX5 + help + This enables the system reset driver support for Intel SOCFPGA + AGILEX5 device. + config SYSRESET_TI_SCI bool "TI System Control Interface (TI SCI) system reset driver" depends on TI_SCI_PROTOCOL diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile index 40c876764a..6631a71db6 100644 --- a/drivers/sysreset/Makefile +++ b/drivers/sysreset/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o obj-$(CONFIG_SYSRESET_SBI) += sysreset_sbi.o obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o obj-$(CONFIG_SYSRESET_SOCFPGA_SOC64) += sysreset_socfpga_soc64.o +obj-$(CONFIG_SYSRESET_SOCFPGA_AGILEX5) += sysreset_socfpga_agilex5.o obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o diff --git a/drivers/sysreset/sysreset_socfpga_agilex5.c b/drivers/sysreset/sysreset_socfpga_agilex5.c new file mode 100644 index 00..7b05ffd269 --- /dev/null +++ b/drivers/sysreset/sysreset_socfpga_agilex5.c @@ -0,0 +1,44 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Intel Corporation + * + */ + +#include +#include +#include +#include +#include +#include +#include + +static int socfpga_sysreset_request(struct udevice *dev, + enum sysreset_t type) +{ +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) + const char *reset = env_get("reset"); + + if (reset && !strcmp(reset, "warm")) { + /* request a warm reset */ + puts("Do warm reset now...\n"); + + /* doing architecture system reset */ + psci_system_reset2(0, 0); + } else { + puts("Issuing cold reset REBOOT_HPS\n"); + psci_system_reset(); + } +#endif + + return -EINPROGRESS; +} + +static struct sysreset_ops socfpga_sysreset = { + .request = socfpga_sysreset_request, +}; + +U_BOOT_DRIVER(sysreset_socfpga) = { + .id = UCLASS_SYSRESET, + .name = "socfpga_sysreset", + .ops= &socfpga_sysreset, +}; -- 2.26.2
[PATCH v1 13/17] drivers: reset: add reset driver for agilex5
This is for new platform enablement for agilex5. Add reset driver for new platform. Signed-off-by: Jit Loon Lim --- drivers/reset/reset-socfpga.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c index 6e3f03e248..8b35f0685d 100644 --- a/drivers/reset/reset-socfpga.c +++ b/drivers/reset/reset-socfpga.c @@ -24,9 +24,18 @@ #include #include #include - -#define BANK_INCREMENT 4 -#define NR_BANKS 8 +#include + +#define BANK_INCREMENT 4 +#define NR_BANKS 8 +#define RSTMGR_PER0MODRST_USB31BIT(4) +#define RSTMGR_PER0MODRST_NAND BIT(5) +#define RSTMGR_PER0MODRST_DMA BIT(16) +#define RSTMGR_PER0MODRST_DMAIFGENMASK(31, 24) +#define RSTMGR_PER0MODRST_USB31_NAND_DMA_DEASSERT RSTMGR_PER0MODRST_USB31 \ + | RSTMGR_PER0MODRST_NAND \ + | RSTMGR_PER0MODRST_DMA \ + | RSTMGR_PER0MODRST_DMAIF struct socfpga_reset_data { void __iomem *modrst_base; @@ -112,9 +121,22 @@ static int socfpga_reset_remove(struct udevice *dev) { struct socfpga_reset_data *data = dev_get_priv(dev); +/* + * TODO: This is temporary solution for NAND/DMA/USB3.1 deaasert. + * When NAND/DMA/USB3.1 driver is ready, the deassert shall be done + * from NAND/DMA/USB3.1 driver. + */ +#if defined(CONFIG_TARGET_SOCFPGA_AGILEX5) + clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_SOC64_PER0MODRST, +RSTMGR_PER0MODRST_USB31_NAND_DMA_DEASSERT); +#endif + if (socfpga_reset_keep_enabled()) { puts("Deasserting all peripheral resets\n"); writel(0, data->modrst_base + 4); +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) + writel(0, data->modrst_base + 8); +#endif } return 0; -- 2.26.2
[PATCH v1 11/17] drivers: mmc: add mmc/cadence driver for agilex5
This is for new platform enablement for agilex5. Add mmc and cadence host driver for new platform. Signed-off-by: Jit Loon Lim --- drivers/mmc/mmc.c | 27 +++--- drivers/mmc/sdhci-cadence.c | 164 2 files changed, 160 insertions(+), 31 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 1af6af82e6..88c674d44f 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -26,6 +26,7 @@ #include #include "mmc_private.h" +#define TIMEOUT_TEN_MS 10 #define DEFAULT_CMD6_TIMEOUT_MS 500 static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage); @@ -247,7 +248,7 @@ static int mmc_send_cmd_retry(struct mmc *mmc, struct mmc_cmd *cmd, static int mmc_send_cmd_quirks(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data, u32 quirk, uint retries) { - if (IS_ENABLED(CONFIG_MMC_QUIRKS) && mmc->quirks & quirk) + if (CONFIG_IS_ENABLED(MMC_QUIRKS) && mmc->quirks & quirk) return mmc_send_cmd_retry(mmc, cmd, data, retries); else return mmc_send_cmd(mmc, cmd, data); @@ -597,6 +598,11 @@ static int sd_send_op_cond(struct mmc *mmc, bool uhs_en) int err; struct mmc_cmd cmd; + /* lower timeout, to speed up mmc init since both uses same flow */ + if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_EMU) || + IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS)) + timeout = TIMEOUT_TEN_MS; + while (1) { cmd.cmdidx = MMC_CMD_APP_CMD; cmd.resp_type = MMC_RSP_R1; @@ -635,7 +641,7 @@ static int sd_send_op_cond(struct mmc *mmc, bool uhs_en) break; if (timeout-- <= 0) - return -EOPNOTSUPP; + return -ETIMEDOUT; udelay(1000); } @@ -2432,9 +2438,6 @@ static int mmc_startup_v4(struct mmc *mmc) mmc->wr_rel_set = ext_csd[EXT_CSD_WR_REL_SET]; - mmc->can_trim = - !!(ext_csd[EXT_CSD_SEC_FEATURE] & EXT_CSD_SEC_FEATURE_TRIM_EN); - return 0; error: if (mmc->ext_csd) { @@ -3130,10 +3133,9 @@ int mmc_init_device(int num) #endif #ifdef CONFIG_CMD_BKOPS_ENABLE -int mmc_set_bkops_enable(struct mmc *mmc, bool autobkops, bool enable) +int mmc_set_bkops_enable(struct mmc *mmc) { int err; - u32 bit = autobkops ? BIT(1) : BIT(0); ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN); err = mmc_send_ext_csd(mmc, ext_csd); @@ -3147,21 +3149,18 @@ int mmc_set_bkops_enable(struct mmc *mmc, bool autobkops, bool enable) return -EMEDIUMTYPE; } - if (enable && (ext_csd[EXT_CSD_BKOPS_EN] & bit)) { + if (ext_csd[EXT_CSD_BKOPS_EN] & 0x1) { puts("Background operations already enabled\n"); return 0; } - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BKOPS_EN, -enable ? bit : 0); + err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BKOPS_EN, 1); if (err) { - printf("Failed to %sable manual background operations\n", - enable ? "en" : "dis"); + puts("Failed to enable manual background operations\n"); return err; } - printf("%sabled %s background operations\n", - enable ? "En" : "Dis", autobkops ? "auto" : "manual"); + puts("Enabled manual background operations\n"); return 0; } diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c index 327a05ad11..4154fd33da 100644 --- a/drivers/mmc/sdhci-cadence.c +++ b/drivers/mmc/sdhci-cadence.c @@ -5,7 +5,10 @@ */ #include +#include #include +#include +#include #include #include #include @@ -16,10 +19,15 @@ #include #include #include +#include #include +/* General define */ +#define SD_MIN_CLK 40 + /* HRS - Host Register Set (specific to Cadence) */ #define SDHCI_CDNS_HRS04 0x10/* PHY access port */ +#define SDHCI_CDNS_HRS05 0x14/* PHY data access port */ #define SDHCI_CDNS_HRS04_ACK BIT(26) #define SDHCI_CDNS_HRS04_RD BIT(25) #define SDHCI_CDNS_HRS04_WR BIT(24) @@ -66,6 +74,16 @@ struct sdhci_cdns_plat { struct mmc_config cfg; struct mmc mmc; void __iomem *hrs_addr; + struct udevice *udev; + struct phy phy_dev; + bool phy_enabled; + struct reset_ctl softreset_ctl; +}; + +/* socfpga implementation specific driver private data */ +struct sdhci_socfpga_priv_data { + struct sdhci_host host; + struct phy phy; }; struct sdhci_cdns_phy_cfg { @@ -94,25 +112,45 @@ static int sdhci_cdns_write_phy_reg(struct sdhci_cdns_plat *plat, u32 tmp; int ret; - tmp = FIELD_PREP(SDHCI_CDNS_HRS04_WDATA, data) | -
[PATCH v1 09/17] drivers: clk: altera: add clock support for agilex5
This is for new platform enablement for agilex5. Add new clock files for new platform.Add Signed-off-by: Jit Loon Lim --- drivers/clk/altera/Makefile | 1 + drivers/clk/altera/clk-agilex5.c | 736 +++ drivers/clk/altera/clk-agilex5.h | 263 +++ 3 files changed, 1000 insertions(+) create mode 100644 drivers/clk/altera/clk-agilex5.c create mode 100644 drivers/clk/altera/clk-agilex5.h diff --git a/drivers/clk/altera/Makefile b/drivers/clk/altera/Makefile index 33db092918..61ffa4179a 100644 --- a/drivers/clk/altera/Makefile +++ b/drivers/clk/altera/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += clk-agilex.o obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += clk-arria10.o obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-n5x.o obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-mem-n5x.o +obj-$(CONFIG_TARGET_SOCFPGA_AGILEX5) += clk-agilex5.o diff --git a/drivers/clk/altera/clk-agilex5.c b/drivers/clk/altera/clk-agilex5.c new file mode 100644 index 00..05ee5f9874 --- /dev/null +++ b/drivers/clk/altera/clk-agilex5.c @@ -0,0 +1,736 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019-2023 Intel Corporation + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define MPIDR_AFF1_OFFSET 8 +#define MPIDR_AFF1_MASK0x3 +#define CORE0 1 +#define CORE1 2 +#define CORE2 3 +#define CORE3 4 + +struct socfpga_clk_plat { + void __iomem *regs; +}; + +/* + * function to write the bypass register which requires a poll of the + * busy bit + */ +static void clk_write_bypass_mainpll(struct socfpga_clk_plat *plat, u32 val) +{ + CM_REG_WRITEL(plat, val, CLKMGR_MAINPLL_BYPASS); + cm_wait_for_fsm(); +} + +static void clk_write_bypass_perpll(struct socfpga_clk_plat *plat, u32 val) +{ + CM_REG_WRITEL(plat, val, CLKMGR_PERPLL_BYPASS); + cm_wait_for_fsm(); +} + +/* function to write the ctrl register which requires a poll of the busy bit */ +static void clk_write_ctrl(struct socfpga_clk_plat *plat, u32 val) +{ + CM_REG_WRITEL(plat, val, CLKMGR_CTRL); + cm_wait_for_fsm(); +} + +#define MEMBUS_MAINPLL 0 +#define MEMBUS_PERPLL 1 +#define MEMBUS_TIMEOUT 1000 + +#define MEMBUS_CLKSLICE_REG0x27 +#define MEMBUS_SYNTHCALFOSC_INIT_CENTERFREQ_REG0xb3 +#define MEMBUS_SYNTHPPM_WATCHDOGTMR_VF01_REG 0xe6 +#define MEMBUS_CALCLKSLICE0_DUTY_LOCOVR_REG0x03 +#define MEMBUS_CALCLKSLICE1_DUTY_LOCOVR_REG0x07 + +static const struct { + u32 reg; + u32 val; + u32 mask; +} membus_pll[] = { + { + MEMBUS_CLKSLICE_REG, + /* +* BIT[7:7] +* Enable source synchronous mode +*/ + BIT(7), + BIT(7) + }, + { + MEMBUS_SYNTHCALFOSC_INIT_CENTERFREQ_REG, + /* +* BIT[0:0] +* Sets synthcalfosc_init_centerfreq=1 to limit overshoot +* frequency during lock +*/ + BIT(0), + BIT(0) + }, + { + MEMBUS_SYNTHPPM_WATCHDOGTMR_VF01_REG, + /* +* BIT[0:0] +* Sets synthppm_watchdogtmr_vf0=1 to give the pll more time +* to settle before lock is asserted. +*/ + BIT(0), + BIT(0) + }, + { + MEMBUS_CALCLKSLICE0_DUTY_LOCOVR_REG, + /* +* BIT[6:0] +* Centering duty cycle for clkslice0 output +*/ + 0x4a, + GENMASK(6, 0) + }, + { + MEMBUS_CALCLKSLICE1_DUTY_LOCOVR_REG, + /* +* BIT[6:0] +* Centering duty cycle for clkslice1 output +*/ + 0x4a, + GENMASK(6, 0) + }, +}; + +static int membus_wait_for_req(struct socfpga_clk_plat *plat, u32 pll, + int timeout) +{ + int cnt = 0; + u32 req_status; + + if (pll == MEMBUS_MAINPLL) + req_status = CM_REG_READL(plat, CLKMGR_MAINPLL_MEM); + else + req_status = CM_REG_READL(plat, CLKMGR_PERPLL_MEM); + + while ((cnt < timeout) && (req_status & CLKMGR_MEM_REQ_SET_MSK)) { + if (pll == MEMBUS_MAINPLL) + req_status = CM_REG_READL(plat, CLKMGR_MAINPLL_MEM); + else + req_status = CM_REG_READL(plat, CLKMGR_PERPLL_MEM); + cnt++; + } + + if (cnt >= timeout) + return -ETIMEDOUT; + + return 0; +} + +static int membus_write_pll(struct socfpga_clk_pl
[PATCH v1 08/17] drivers: ddr: altera: add ddr support for agilex5
This is for new platform enablement for agilex5. Add new ddr and iossm mailbox files for new platform.Add Signed-off-by: Jit Loon Lim --- drivers/ddr/altera/Makefile| 5 +- drivers/ddr/altera/iossm_mailbox.c | 786 + drivers/ddr/altera/iossm_mailbox.h | 141 ++ drivers/ddr/altera/sdram_agilex5.c | 329 drivers/ddr/altera/sdram_soc64.c | 78 ++- drivers/ddr/altera/sdram_soc64.h | 17 +- 6 files changed, 1345 insertions(+), 11 deletions(-) create mode 100644 drivers/ddr/altera/iossm_mailbox.c create mode 100644 drivers/ddr/altera/iossm_mailbox.h create mode 100644 drivers/ddr/altera/sdram_agilex5.c diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile index 9fa5d85a27..fa6c880b39 100644 --- a/drivers/ddr/altera/Makefile +++ b/drivers/ddr/altera/Makefile @@ -7,9 +7,10 @@ # Copyright (C) 2014-2021 Altera Corporation ifdef CONFIG_$(SPL_)ALTERA_SDRAM -obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o -obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o +obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_soc32.o sdram_gen5.o sequencer.o +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_soc32.o sdram_arria10.o obj-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += sdram_soc64.o sdram_s10.o obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += sdram_soc64.o sdram_agilex.o obj-$(CONFIG_TARGET_SOCFPGA_N5X) += sdram_soc64.o sdram_n5x.o +obj-$(CONFIG_TARGET_SOCFPGA_AGILEX5) += sdram_soc64.o sdram_agilex5.o iossm_mailbox.o endif diff --git a/drivers/ddr/altera/iossm_mailbox.c b/drivers/ddr/altera/iossm_mailbox.c new file mode 100644 index 00..c7ceed7c45 --- /dev/null +++ b/drivers/ddr/altera/iossm_mailbox.c @@ -0,0 +1,786 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Intel Corporation + * + */ + +#define DEBUG +#include +#include +#include +#include "iossm_mailbox.h" +#include + +/* supported DDR type list */ +static const char *ddr_type_list[7] = { + "DDR4", "DDR5", "DDR5_RDIMM", "LPDDR4", "LPDDR5", "QDRIV", "UNKNOWN" +}; + +/* Mailbox request function + * This function will send the request to IOSSM mailbox and wait for response return + * + * @io96b_csr_addr: CSR address for the target IO96B + * @ip_type: IP type for the specified memory interface + * @instance_id:IP instance ID for the specified memory interface + * @usr_cmd_type: User desire IOSSM mailbox command type + * @usr_cmd_opcode: User desire IOSSM mailbox command opcode + * @cmd_param_*:Parameters (if applicable) for the requested IOSSM mailbox command + * @resp_data_len: User desire extra response data fields other than + * CMD_RESPONSE_DATA_SHORT field on CMD_RESPONSE_STATUS + * @resp: Structure contain responses returned from the requested IOSSM + * mailbox command + */ +int io96b_mb_req(phys_addr_t io96b_csr_addr, u32 ip_type, u32 instance_id + , u32 usr_cmd_type, u32 usr_cmd_opcode, u32 cmd_param_0 + , u32 cmd_param_1, u32 cmd_param_2, u32 cmd_param_3 + , u32 cmd_param_4, u32 cmd_param_5, u32 cmd_param_6 + , u32 resp_data_len, struct io96b_mb_resp *resp) +{ + int i; + int ret; + u32 cmd_req, cmd_resp; + + /* Initialized zeros for responses*/ + resp->cmd_resp_status = 0; + resp->cmd_resp_data_0 = 0; + resp->cmd_resp_data_1 = 0; + resp->cmd_resp_data_2 = 0; + + /* Ensure CMD_REQ is cleared before write any command request */ + ret = wait_for_bit_le32((const void *)(io96b_csr_addr + IOSSM_CMD_REQ_OFFSET) + , GENMASK(31, 0), 0, TIMEOUT, false); + + if (ret) { + printf("%s: CMD_REQ not ready\n", __func__); + return -1; + } + + /* Write CMD_PARAM_* */ + for (i = 0; i < 6 ; i++) { + switch (i) { + case 0: + if (cmd_param_0) + writel(cmd_param_0, io96b_csr_addr + IOSSM_CMD_PARAM_0_OFFSET); + break; + case 1: + if (cmd_param_1) + writel(cmd_param_1, io96b_csr_addr + IOSSM_CMD_PARAM_1_OFFSET); + break; + case 2: + if (cmd_param_2) + writel(cmd_param_2, io96b_csr_addr + IOSSM_CMD_PARAM_2_OFFSET); + break; + case 3: + if (cmd_param_3) + writel(cmd_param_3, io96b_csr_addr + IOSSM_CMD_PARAM_3_OFFSET); + break; + case 4: + if (cmd_param_4) + writel(cmd_param_4, io96b_csr_addr + IOSSM_CMD_PARAM_4_OFFSET); +
[PATCH v1 10/17] drivers: misc: update driver misc for agilex5
This is for new platform enablement for agilex5. Update secure registers, Kconfig and makefile for new platform. Signed-off-by: Jit Loon Lim --- drivers/misc/Kconfig | 9 +++ drivers/misc/Makefile | 1 + drivers/misc/socfpga_secreg.c | 116 ++ 3 files changed, 126 insertions(+) create mode 100644 drivers/misc/socfpga_secreg.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 04460f1acb..3b6f5314ff 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -666,4 +666,13 @@ config SL28CPLD the base driver which provides common access methods for the sub-drivers. +config SPL_SOCFPGA_SEC_REG + bool "Enable register setting from device tree in SPL" + depends on SPL + help + Enable register setting from device tree in SPL, which require + high privilege access like firewall registers. This also + provides user a clean interface and all register settings are + centralized in one place, device tree. + endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 52aed09602..441c03509f 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -88,3 +88,4 @@ obj-$(CONFIG_K3_AVS0) += k3_avs.o obj-$(CONFIG_ESM_K3) += k3_esm.o obj-$(CONFIG_ESM_PMIC) += esm_pmic.o obj-$(CONFIG_SL28CPLD) += sl28cpld.o +obj-$(CONFIG_SPL_SOCFPGA_SEC_REG) += socfpga_secreg.o diff --git a/drivers/misc/socfpga_secreg.c b/drivers/misc/socfpga_secreg.c new file mode 100644 index 00..3f3ba8b0c1 --- /dev/null +++ b/drivers/misc/socfpga_secreg.c @@ -0,0 +1,116 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2021-2023 Intel Corporation + */ + +#include +#include +#include +#include +#include + +#define NUMBER_OF_ELEMENTS 3 + +static int socfpga_secreg_probe(struct udevice *dev) +{ + const fdt32_t *list; + fdt_addr_t offset, base; + fdt_val_t val, read_val, mask, set_mask; + int size, i; + u32 blk_sz, reg; + ofnode node; + const char *name = NULL; + + debug("%s(dev=%p)\n", __func__, dev); + + if (!dev_has_ofnode(dev)) + return 0; + + dev_for_each_subnode(node, dev) { + name = ofnode_get_name(node); + if (!name) + return -EINVAL; + + if (ofnode_read_u32_index(node, "reg", 1, &blk_sz)) + return -EINVAL; + + base = ofnode_get_addr(node); + if (base == FDT_ADDR_T_NONE) + return -EINVAL; + + debug("%s(node_offset 0x%lx node_name %s ", __func__, + node.of_offset, name); + debug("node addr 0x%llx blk sz 0x%x)\n", base, blk_sz); + + list = ofnode_read_prop(node, "intel,offset-settings", &size); + if (!list) + return -EINVAL; + + debug("%s(intel,offset-settings property size=%x)\n", __func__, + size); + size /= sizeof(*list) * NUMBER_OF_ELEMENTS; + + /* +* First element: offset +* Second element: val +* Third element: mask +*/ + for (i = 0; i < size; i++) { + offset = fdt32_to_cpu(*list++); + val = fdt32_to_cpu(*list++); + + /* Reads the masking bit value from the list */ + mask = fdt32_to_cpu(*list++); + + /* +* Reads out the offsets, value and masking bits +* Ex: <0x 0x0230 0x> +*/ + debug("%s(intel,offset-settings 0x%llx : 0x%llx : 0x%llx)\n", + __func__, offset, val, mask); + + if (blk_sz < offset + SZ_4) { + printf("%s: Overflow as offset 0x%llx or reg", + __func__, offset); + printf(" write is more than block size 0x%x\n", + blk_sz); + return -EINVAL; + } + + if (mask != 0) { + if (mask == 0x) { + reg = base + offset; + writel(val, (uintptr_t)reg); + } else { + /* Mask the value with the masking bits */ + set_mask = val & mask; + + reg = base + offset; + + /* Clears and sets specific bits in the register */ + clrsetbits_le32((uintptr_t)reg, mask, set_mask); + } +
[PATCH v1 06/17] configs: add new platform agilex5 defconfig
This is for new platform enablement for agilex5. Add new platform defconfig for new platform. Signed-off-by: Jit Loon Lim --- configs/socfpga_agilex5_defconfig| 123 +++ configs/socfpga_agilex5_legacy_defconfig | 85 2 files changed, 208 insertions(+) create mode 100644 configs/socfpga_agilex5_defconfig create mode 100644 configs/socfpga_agilex5_legacy_defconfig diff --git a/configs/socfpga_agilex5_defconfig b/configs/socfpga_agilex5_defconfig new file mode 100644 index 00..6a90fa0b27 --- /dev/null +++ b/configs/socfpga_agilex5_defconfig @@ -0,0 +1,123 @@ +CONFIG_ARM=y +CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds" +CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200 +CONFIG_ARCH_SOCFPGA=y +CONFIG_TEXT_BASE=0x8020 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_NR_DRAM_BANKS=2 +CONFIG_ENV_SIZE=0x2000 +CONFIG_DM_GPIO=y +CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex5_socdk" +# CONFIG_SPL_MMC is not set +CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y +CONFIG_TARGET_SOCFPGA_AGILEX5_SOCDK=y +CONFIG_IDENT_STRING="socfpga_agilex5" +CONFIG_SPL_FS_FAT=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SPL_FIT_SIGNATURE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_LOAD_FIT_ADDRESS=0x8200 +# CONFIG_USE_SPL_FIT_GENERATOR is not set +CONFIG_QSPI_BOOT=y +CONFIG_BOOTDELAY=5 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200 initrd=0x9000 root=/dev/ram0 rw init=/sbin/init ramdisk_size=1000 earlycon panic=-1 nosmp kvm-arm.mode=nvhe" +CONFIG_LEGACY_IMAGE_FORMAT=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_CRC32=y +CONFIG_SPL_CACHE=y +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_SYS_PROMPT="SOCFPGA_AGILEX5 # " +CONFIG_CMD_NVEDIT_SELECT=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_PHY=y +CONFIG_SPL_PHY=y +CONFIG_PHY_CADENCE_COMBOPHY=y +CONFIG_DM_MMC=y +CONFIG_SPL_MMC=y +CONFIG_SPL_DM_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_ADMA=y +CONFIG_SPL_MMC_SDHCI_ADMA=y +CONFIG_MMC_SDHCI_CADENCE=y +CONFIG_CMD_FAT=y +CONFIG_DOS_PARTITION=y +CONFIG_SPL_DOS_PARTITION=y +CONFIG_SPL_SYS_DISABLE_DCACHE_OPS=y +CONFIG_CMD_MTD=y +CONFIG_CMD_NAND_TRIMFFS=y +CONFIG_CMD_NAND_LOCK_UNLOCK=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_CACHE=y +CONFIG_MTDIDS_DEFAULT="nand0=ffb9.nand.0" +CONFIG_MTDPARTS_DEFAULT="mtdparts=ffb9.nand.0:2m(u-boot),-(root)" +CONFIG_CMD_UBI=y +# CONFIG_ISO_PARTITION is not set +# CONFIG_EFI_PARTITION is not set +CONFIG_OF_LIST="" +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_ALTERA_SDRAM=y +CONFIG_FPGA_INTEL_PR=y +CONFIG_DWAPB_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_DW=y +CONFIG_MISC=y +CONFIG_MMC_DW=y +CONFIG_MTD=y +CONFIG_DM_MTD=y +CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y +CONFIG_SYS_NAND_U_BOOT_OFFS=0x0 +CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x10 +CONFIG_SF_DEFAULT_MODE=0x2003 +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_UBI_SILENCE_MSG=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_MII=y +CONFIG_DM_RESET=y +CONFIG_SPI=y +CONFIG_CADENCE_QSPI=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_NOP_PHY=y +CONFIG_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_DWC3=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_UBIFS_SILENCE_MSG=y +# CONFIG_SPL_USE_TINY_PRINTF is not set +CONFIG_PANIC_HANG=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_LOAD_ADDR=0x8200 +CONFIG_WDT=y +CONFIG_CMD_WDT=y +CONFIG_DESIGNWARE_WATCHDOG=y +CONFIG_SPL_WDT=y +CONFIG_WATCHDOG_AUTOSTART=n +CONFIG_TIMER=y +CONFIG_DESIGNWARE_APB_TIMER=y +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8030 +CONFIG_SPL_MAX_SIZE=0x4 +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y +CONFIG_SPL_BSS_START_ADDR=0x8ff0 +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set +CONFIG_SPL_STACK=0xffe3f000 +CONFIG_SYS_SPL_MALLOC=y +CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y +CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8fa0 +CONFIG_SYS_SPL_MALLOC_SIZE=0x50 +CONFIG_SPL_BSS_MAX_SIZE=0x10 +# CONFIG_EFI_LOADER is not set diff --git a/configs/socfpga_agilex5_legacy_defconfig b/configs/socfpga_agilex5_legacy_defconfig new file mode 100644 index 00..cede11c880 --- /dev/null +++ b/configs/socfpga_agilex5_legacy_defconfig @@ -0,0 +1,85 @@ +CONFIG_ARM=y +CONFIG_ARM_SMCCC=y +CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds" +CONFIG_ARCH_SOCFPGA=y +CONFIG_SYS_TEXT_BASE=0x80001000 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_NR_DRAM_BANKS=2 +CONFIG_ENV_SIZE=0x2000 +CONFIG_DM_GPIO=y +# CONFIG_SPL_DM_SPI is not set +CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex5_socdk" +CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y +CONFIG_TARGET_SOCFPGA_AGILEX5_SOCDK=y +CONFIG_IDENT_STRING="socfpga_agilex5" +CONFIG_SPL_FS_FAT=y +# CONFIG_SPL_SPI is not set +CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y +CONFIG_SYS_LOAD_ADDR=0x8200 +CONFIG_ARMV8_PSCI=y +# CONFIG_PSCI_RESET is not set +CONFIG_BOOTDELAY=5 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARG
[PATCH v1 07/17] doc: device-tree-bindings: misc: add secreg text file for agilex5
This is for new platform enablement for agilex5. Add new secure register text file for new platform. Signed-off-by: Jit Loon Lim --- .../misc/socfpga_secreg.txt | 397 ++ 1 file changed, 397 insertions(+) create mode 100644 doc/device-tree-bindings/misc/socfpga_secreg.txt diff --git a/doc/device-tree-bindings/misc/socfpga_secreg.txt b/doc/device-tree-bindings/misc/socfpga_secreg.txt new file mode 100644 index 00..97640b74d9 --- /dev/null +++ b/doc/device-tree-bindings/misc/socfpga_secreg.txt @@ -0,0 +1,397 @@ +* Firewall and privilege register settings in device tree + +Required properties: + + +- compatible: should contain "intel,socfpga-secreg" +- reg: Physical base address and size of block register. +- intel,offset-settings: 32-bit offset address of block register, +followed by 32-bit value settings and +the masking bits, only masking bit +set to 1 allows modification. + +The device tree node which describes secure and privilege register access +configuration in compile time. + +Most of these registers are expected to work except for the case which some +registers configuration are required for granting access to some other +registers, for example CCU registers have to be properly configured before +allowing register configuration access to fpga2sdram firewall as shown in +below example. + +Some registers depend on runtime data for proper configuration are expected +to be part of driver that generating these data for example configuration for +soc_noc_fw_ddr_mpu_inst_0_ddr_scr block register depend on DDR size parsed from +memory device tree node. + +Please refer details of tested examples below for both fpga2sdram and QoS +configuration with default reset value and the comments. + +Example: + + +Common configuration for all SoC64 devices: +Path: arch/arm/dts/socfpga_soc64_u-boot.dtsi + + socfpga_secreg: socfpga-secreg { + compatible = "intel,socfpga-secreg"; + #address-cells = <1>; + #size-cells = <1>; + u-boot,dm-pre-reloc; + + i_sys_mgr_core@ffd12000 { + reg = <0xffd12000 0x0230>; + intel,offset-settings = + /* Enable non-secure interface to DMA */ + <0x0020 0xff01 0xff010011>, + /* Enable non-secure interface to DMA periph */ + <0x0024 0x 0x>; + u-boot,dm-pre-reloc; + }; + + noc_fw_l4_per_l4_per_scr@ffd21000 { + reg = <0xffd21000 0x0074>; + intel,offset-settings = + /* Disable L4 periphs firewall */ + <0x 0x01010001 0x01010001>, + <0x0004 0x01010001 0x01010001>, + <0x000c 0x01010001 0x01010001>, + <0x0010 0x01010001 0x01010001>, + <0x001c 0x01010001 0x01010101>, + <0x0020 0x01010001 0x01010101>, + <0x0024 0x01010001 0x01010101>, + <0x0028 0x01010001 0x01010101>, + <0x002c 0x01010001 0x01010001>, + <0x0030 0x01010001 0x01010001>, + <0x0034 0x01010001 0x01010001>, + <0x0040 0x01010001 0x01010001>, + <0x0044 0x01010001 0x01010101>, + <0x0048 0x01010001 0x01010101>, + <0x0050 0x01010001 0x01010101>, + <0x0054 0x01010001 0x01010101>, + <0x0058 0x01010001 0x01010101>, + <0x005c 0x01010001 0x01010101>, + <0x0060 0x01010001 0x01010101>, + <0x0064 0x01010001 0x01010101>, + <0x0068 0x01010001 0x01010101>, + <0x006c 0x01010001 0x01010101>, + <0x0070 0x01010001 0x01010101>; + u-boot,dm-pre-reloc; + }; + + noc_fw_l4_sys_l4_sys_scr@ffd21100 { + reg = <0xffd21100 0x0098>; + intel,offset-settings = + /* Disable L4 system firewall */ + <0x0008 0x01010001 0x01010001>, + <0x000c 0x01010001 0x01010001>, + <0x0010 0x01010001 0x01010001>, + <0x0014 0x01
[PATCH v1 05/17] board: intel: add new platform agilex5 socdk
This is for new platform enablement for agilex5. Add new platform socdk and update maintainer list. Signed-off-by: Jit Loon Lim --- board/intel/agilex5-socdk/MAINTAINERS | 8 board/intel/agilex5-socdk/Makefile| 7 +++ board/intel/agilex5-socdk/socfpga.c | 7 +++ 3 files changed, 22 insertions(+) create mode 100644 board/intel/agilex5-socdk/MAINTAINERS create mode 100644 board/intel/agilex5-socdk/Makefile create mode 100644 board/intel/agilex5-socdk/socfpga.c diff --git a/board/intel/agilex5-socdk/MAINTAINERS b/board/intel/agilex5-socdk/MAINTAINERS new file mode 100644 index 00..f0bb2b796b --- /dev/null +++ b/board/intel/agilex5-socdk/MAINTAINERS @@ -0,0 +1,8 @@ +SOCFPGA BOARD +M: Tien Fong Chee +M: Jit Loon Lim +M: Sieu Mun Tang +S: Maintained +F: board/intel/agilex5-socdk/ +F: include/configs/socfpga_agilex5_socdk.h +F: configs/socfpga_agilex5_defconfig diff --git a/board/intel/agilex5-socdk/Makefile b/board/intel/agilex5-socdk/Makefile new file mode 100644 index 00..52f7de8880 --- /dev/null +++ b/board/intel/agilex5-socdk/Makefile @@ -0,0 +1,7 @@ +# +# Copyright (C) 2022 Intel Corporation +# +# SPDX-License-Identifier: GPL-2.0 +# + +obj-y := socfpga.o diff --git a/board/intel/agilex5-socdk/socfpga.c b/board/intel/agilex5-socdk/socfpga.c new file mode 100644 index 00..ae5c04557c --- /dev/null +++ b/board/intel/agilex5-socdk/socfpga.c @@ -0,0 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Intel Corporation + * + */ + +#include -- 2.26.2
[PATCH v1 04/17] arch: arm: mach-socfpga: include: mach: add new platform agilex5 mach-socfpga enablement
This is for new platform enablement for agilex5. Add platform related header files to enable new product. Signed-off-by: Jit Loon Lim --- .../include/mach/base_addr_soc64.h| 43 +- .../mach-socfpga/include/mach/clock_manager.h | 5 +- .../include/mach/clock_manager_agilex5.h | 12 ++ arch/arm/mach-socfpga/include/mach/firewall.h | 42 +- .../mach-socfpga/include/mach/handoff_soc64.h | 25 +++- .../mach-socfpga/include/mach/mailbox_s10.h | 32 +++-- .../include/mach/reset_manager_soc64.h| 33 - .../mach-socfpga/include/mach/smmu_agilex5.h | 30 + arch/arm/mach-socfpga/include/mach/smmu_s10.h | 73 ++ .../include/mach/system_manager_soc64.h | 126 -- arch/arm/mach-socfpga/include/mach/timer.h| 30 + 11 files changed, 419 insertions(+), 32 deletions(-) create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_agilex5.h create mode 100644 arch/arm/mach-socfpga/include/mach/smmu_agilex5.h create mode 100644 arch/arm/mach-socfpga/include/mach/smmu_s10.h diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h index 3f899fcfa3..4a88770638 100644 --- a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h +++ b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h @@ -1,21 +1,60 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* - * Copyright (C) 2016-2021 Intel Corporation + * Copyright (C) 2016-2023 Intel Corporation */ #ifndef _SOCFPGA_SOC64_BASE_HARDWARE_H_ #define _SOCFPGA_SOC64_BASE_HARDWARE_H_ +#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5) +#define SOCFPGA_CCU_ADDRESS0x1c00 +#define SOCFPGA_F2SDRAM_MGR_ADDRESS0x18001000 +#define SOCFPGA_SMMU_ADDRESS 0x1600 +#define SOCFPGA_OCRAM_FIREWALL_ADDRESS 0x108cc400 +#define SOCFPGA_MAILBOX_ADDRESS0x10a3 +#define SOCFPGA_UART0_ADDRESS 0x10c02000 +#define SOCFPGA_UART1_ADDRESS 0x10c02100 +#define SOCFPGA_SPTIMER0_ADDRESS 0x10c03000 +#define SOCFPGA_SPTIMER1_ADDRESS 0x10c03100 +#define SOCFPGA_SYSTIMER0_ADDRESS 0x10d0 +#define SOCFPGA_SYSTIMER1_ADDRESS 0x10d00100 +#define SOCFPGA_L4WD0_ADDRESS 0x10d00200 +#define SOCFPGA_L4WD1_ADDRESS 0x10d00300 +#define SOCFPGA_L4WD2_ADDRESS 0x10d00400 +#define SOCFPGA_L4WD3_ADDRESS 0x10d00500 +#define SOCFPGA_L4WD4_ADDRESS 0x10d00600 +#define SOCFPGA_GTIMER_SEC_ADDRESS 0x10d01000 +#define SOCFPGA_GTIMER_NSEC_ADDRESS0x10d02000 +#define SOCFPGA_CLKMGR_ADDRESS 0x10d1 +#define SOCFPGA_RSTMGR_ADDRESS 0x10d11000 +#define SOCFPGA_SYSMGR_ADDRESS 0x10d12000 +#define SOCFPGA_OCRAM_ADDRESS 0x +#define SOCFPGA_FW_DDR_CCU_DMI0_ADDRESS0x18000800 +#define SOCFPGA_FW_DDR_CCU_DMI1_ADDRESS0x18000A00 +#define SOCFPGA_FW_TBU2NOC_ADDRESS 0x18000C00 +#define SOCFPGA_FIREWALL_L4_PER0xffd21000 /* TODO */ +#define SOCFPGA_FIREWALL_L4_SYS0xffd21100 /* TODO */ +#define SOCFPGA_FIREWALL_SOC2FPGA 0xffd21200 /* TODO */ +#define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300 /* TODO */ +#define SOCFPGA_FIREWALL_TCU 0xffd21400 /* TODO */ +#define SOCFPGA_FIREWALL_PRIV_MEMORYMAP_PRIV 0xffd24800 /* TODO */ +#define SOCFPGA_DMANONSECURE_ADDRESS 0xffda /* TODO */ +#define SOCFPGA_DMASECURE_ADDRESS 0xffda1000 /* TODO */ +#define GICD_BASE 0x1d00 +#define GICR_BASE 0x1d06 +#else #define SOCFPGA_CCU_ADDRESS0xf700 #define SOCFPGA_SDR_SCHEDULER_ADDRESS 0xf8000400 #define SOCFPGA_HMC_MMR_IO48_ADDRESS 0xf801 #define SOCFPGA_SDR_ADDRESS0xf8011000 +#define SOCFPGA_FW_MPFE_SCR_ADDRESS0xf802 #if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) || \ IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X) #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020200 #else #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020100 #endif +#define SOCFPGA_F2SDRAM_MGR_ADDRESS0xf8024000 #define SOCFPGA_SMMU_ADDRESS 0xfa00 #define SOCFPGA_MAILBOX_ADDRESS0xffa3 #define SOCFPGA_UART0_ADDRESS 0xffc02000 @@ -39,10 +78,12 @@ #define SOCFPGA_FIREWALL_SOC2FPGA 0xffd21200 #define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300 #define SOCFPGA_FIREWALL_TCU 0xffd21400 +#define SOCFPGA_FIREWALL_PRIV_MEMORYMAP_PRIV 0xffd24800 #define SOCFPGA_DMANONSECURE_ADDRESS 0xffda #define SOCFPGA_DMASECURE_ADDRESS 0xffda1000 #define SOCFP
[PATCH v1 03/17] arch: arm: mach-socfpga: add new platform agilex5 mach-socfpga enablement
This is for new platform enablement for agilex5. Add platform related files to enable new product. Signed-off-by: Jit Loon Lim --- arch/arm/mach-socfpga/Kconfig | 37 +++ arch/arm/mach-socfpga/Makefile| 69 - arch/arm/mach-socfpga/board.c | 65 - arch/arm/mach-socfpga/clock_manager_agilex5.c | 82 ++ arch/arm/mach-socfpga/firewall.c | 107 --- arch/arm/mach-socfpga/lowlevel_init_agilex5.S | 61 arch/arm/mach-socfpga/lowlevel_init_soc64.S | 167 ++- arch/arm/mach-socfpga/mailbox_s10.c | 21 ++ arch/arm/mach-socfpga/misc.c | 19 +- arch/arm/mach-socfpga/misc_soc64.c| 33 ++- arch/arm/mach-socfpga/mmu-arm64_s10.c | 43 ++- arch/arm/mach-socfpga/reset_manager_s10.c | 271 +++--- arch/arm/mach-socfpga/secure_reg_helper.c | 4 +- arch/arm/mach-socfpga/smmu_agilex5.c | 34 +++ arch/arm/mach-socfpga/smmu_s10.c | 126 arch/arm/mach-socfpga/spl_agilex5.c | 180 arch/arm/mach-socfpga/spl_soc64.c | 188 +++- arch/arm/mach-socfpga/u-boot-spl-soc64.lds| 93 ++ arch/arm/mach-socfpga/wrap_handoff_soc64.c| 7 +- 19 files changed, 1429 insertions(+), 178 deletions(-) create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex5.c delete mode 100644 arch/arm/mach-socfpga/firewall.c create mode 100644 arch/arm/mach-socfpga/lowlevel_init_agilex5.S create mode 100644 arch/arm/mach-socfpga/smmu_agilex5.c create mode 100644 arch/arm/mach-socfpga/smmu_s10.c create mode 100644 arch/arm/mach-socfpga/spl_agilex5.c create mode 100644 arch/arm/mach-socfpga/u-boot-spl-soc64.lds diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 503c82d388..562c3796ec 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -44,6 +44,15 @@ config TEXT_BASE default 0x0140 if TARGET_SOCFPGA_ARRIA10 default 0x0140 if TARGET_SOCFPGA_GEN5 +config ARMV8_PSCI_NR_CPUS + default 4 if TARGET_SOCFPGA_SOC64 + +config ARMV8_SECURE_BASE + default 0x1000 if TARGET_SOCFPGA_SOC64 && ARMV8_PSCI + +config SYS_HAS_ARMV8_SECURE_BASE + default y if TARGET_SOCFPGA_SOC64 && ARMV8_PSCI + config TARGET_SOCFPGA_AGILEX bool select ARMV8_MULTIENTRY @@ -51,10 +60,31 @@ config TARGET_SOCFPGA_AGILEX select BINMAN if SPL_ATF select CLK select FPGA_INTEL_SDM_MAILBOX + select GICV2 + select NCORE_CACHE + select SPL_CLK if SPL + select TARGET_SOCFPGA_SOC64 + +config TARGET_SOCFPGA_AGILEX5 + bool + select BINMAN if SPL_ATF + select CLK + select FPGA_INTEL_SDM_MAILBOX + select GICV3 select NCORE_CACHE select SPL_CLK if SPL select TARGET_SOCFPGA_SOC64 +config TARGET_SOCFPGA_AGILEX5_EMU + bool "Enable build that bootable only on Agilex5 Emulator" + help +This is to use for Agilex5 Emulator. + +config TARGET_SOCFPGA_AGILEX5_SIMICS + bool "Enable build that bootable only on Agilex5 Simics platform" + help +This is to use for Agilex5 Simics. + config TARGET_SOCFPGA_ARRIA5 bool select TARGET_SOCFPGA_GEN5 @@ -126,6 +156,10 @@ config TARGET_SOCFPGA_AGILEX_SOCDK bool "Intel SOCFPGA SoCDK (Agilex)" select TARGET_SOCFPGA_AGILEX +config TARGET_SOCFPGA_AGILEX5_SOCDK + bool "Intel SOCFPGA SoCDK (Agilex5)" + select TARGET_SOCFPGA_AGILEX5 + config TARGET_SOCFPGA_ARIES_MCVEVK bool "Aries MCVEVK (Cyclone V)" select TARGET_SOCFPGA_CYCLONE5 @@ -199,6 +233,7 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT endchoice config SYS_BOARD + default "agilex5-socdk" if TARGET_SOCFPGA_AGILEX5_SOCDK default "agilex-socdk" if TARGET_SOCFPGA_AGILEX_SOCDK default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK default "arria10-socdk" if TARGET_SOCFPGA_ARRIA10_SOCDK @@ -220,6 +255,7 @@ config SYS_BOARD default "vining_fpga" if TARGET_SOCFPGA_SOFTING_VINING_FPGA config SYS_VENDOR + default "intel" if TARGET_SOCFPGA_AGILEX5_SOCDK default "intel" if TARGET_SOCFPGA_AGILEX_SOCDK default "intel" if TARGET_SOCFPGA_N5X_SOCDK default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK @@ -242,6 +278,7 @@ config SYS_SOC default "socfpga" config SYS_CONFIG_NAME + default "socfpga_agilex5_socdk" if TARGET_SOCFPGA_AGILEX5_SOCDK default "socfpga_agilex_socdk" if TARGET_SOCFPGA_AGILEX_SOCDK default "socfpga_arria5_secu1" if TARGET_SOCFPGA_ARRIA5_SECU1 default "socfpga_arria5_socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile index ec38b64dd4..771e7ce77d 100644 --- a/arch/arm/mach-socfpga/Makefile +++ b/arch/arm/mach-socfpga/Makefile @@ -35,10 +35,22 @@ obj-y += mailbox_s10.o obj-y += misc_s
[PATCH v1 02/17] arch: arm: dts: add dts and dtsi for new platform agilex5
This is for new platform enablement for agilex5. Add agilex5 dtsi and dts. Update checkpatch error for stratix10. Signed-off-by: Jit Loon Lim --- arch/arm/dts/Makefile | 1 + arch/arm/dts/socfpga_agilex5-u-boot.dtsi | 459 + arch/arm/dts/socfpga_agilex5.dtsi | 634 ++ .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 131 arch/arm/dts/socfpga_agilex5_socdk.dts| 165 + arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi| 38 +- arch/arm/dts/socfpga_soc64_u-boot.dtsi| 120 arch/arm/dts/socfpga_stratix10.dtsi | 0 .../dts/socfpga_stratix10_socdk-u-boot.dtsi | 0 arch/arm/dts/socfpga_stratix10_socdk.dts | 0 10 files changed, 1534 insertions(+), 14 deletions(-) create mode 100644 arch/arm/dts/socfpga_agilex5-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_agilex5.dtsi create mode 100644 arch/arm/dts/socfpga_agilex5_socdk-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_agilex5_socdk.dts create mode 100644 arch/arm/dts/socfpga_soc64_u-boot.dtsi mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10.dtsi mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi mode change 100755 => 100644 arch/arm/dts/socfpga_stratix10_socdk.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 480269fa60..2e4bc556e1 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -456,6 +456,7 @@ dtb-$(CONFIG_TARGET_THUNDERX_88XX) += thunderx-88xx.dtb dtb-$(CONFIG_ARCH_SOCFPGA) += \ socfpga_agilex_socdk.dtb\ + socfpga_agilex5_socdk.dtb \ socfpga_arria5_secu1.dtb\ socfpga_arria5_socdk.dtb\ socfpga_arria10_chameleonv3_270_2.dtb \ diff --git a/arch/arm/dts/socfpga_agilex5-u-boot.dtsi b/arch/arm/dts/socfpga_agilex5-u-boot.dtsi new file mode 100644 index 00..6a1299901a --- /dev/null +++ b/arch/arm/dts/socfpga_agilex5-u-boot.dtsi @@ -0,0 +1,459 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * U-Boot additions + * + * Copyright (C) 2019-2022 Intel Corporation + */ + +#include "socfpga_soc64_u-boot.dtsi" +#include "socfpga_soc64_fit-u-boot.dtsi" + +/{ + memory { + #address-cells = <2>; + #size-cells = <2>; + bootph-all; + }; + + soc { + bootph-all; + + socfpga_secreg: socfpga-secreg { + compatible = "intel,socfpga-secreg"; + #address-cells = <1>; + #size-cells = <1>; + bootph-all; + + /* DSU */ + i_ccu_caiu0@1c00 { + reg = <0x1c00 0x1000>; + intel,offset-settings = + /* CAIUAMIGR */ + <0x03c0 0x0003 0x001f>, + /* CAIUMIFSR */ + <0x03c4 0x 0x07070777>, + /* DII1_MPFEREGS */ + <0x0414 0x00018000 0x>, + <0x0418 0x 0x00ff>, + <0x0410 0xc0e00200 0xc1f03e1f>, + /* DII2_GICREGS */ + <0x0424 0x0001d000 0x>, + <0x0428 0x 0x00ff>, + <0x0420 0xc0800400 0xc1f03e1f>, + /* NCAIU0_LWSOC2FPGA */ + <0x0444 0x0002 0x>, + <0x0448 0x 0x00ff>, + <0x0440 0xc116 0xc1f03e1f>, + /* NCAIU0_SOC2FPGA_1G */ + <0x0454 0x0004 0x>, + <0x0458 0x 0x00ff>, + <0x0450 0xc126 0xc1f03e1f>, + /* DMI_SDRAM_2G */ + <0x0464 0x0008 0x>, + <0x0468 0x 0x00ff>, + <0x0460 0x8136 0xc1f03e1f>, + /* NCAIU0_SOC2FPGA_16G */ + <0x0474 0x0040 0x>, + <0x0478 0x 0x00ff>, + <0x0470 0xc166 0xc1f03e1f>, + /* DMI_SDRAM_30G */ +
[PATCH v1 01/17] arch: arm: update kconfig for new platform agilex5
This is for new platform enablement for agilex5 Signed-off-by: Jit Loon Lim --- arch/arm/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 99264a6478..8e36456fa8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1093,6 +1093,8 @@ config ARCH_SOCFPGA select SPL_LIBGENERIC_SUPPORT select SPL_OF_CONTROL select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64 + select SPL_DRIVERS_MISC if TARGET_SOCFPGA_SOC64 + select SPL_SOCFPGA_SEC_REG if TARGET_SOCFPGA_SOC64 select SPL_SERIAL select SPL_SYSRESET select SPL_WATCHDOG @@ -1101,7 +1103,8 @@ config ARCH_SOCFPGA select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 select SYSRESET select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 - select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_SOC64 + select SYSRESET_SOCFPGA_SOC64 if !TARGET_SOCFPGA_AGILEX5 && TARGET_SOCFPGA_SOC64 + imply SYSRESET_SOCFPGA_AGILEX5 if TARGET_SOCFPGA_AGILEX5 imply CMD_DM imply CMD_MTDPARTS imply CRC32_VERIFY -- 2.26.2
[PATCH v1 00/17] Agilex5 Platform Enablement
Intel Agilex5 is a midrange FPGAs optimized for applications requiring high performance, lower power, and smaller form factors and lower logic densities. U-Boot is one of the bootloader to boot along with ARM trusted Firmware to boot the board up. *** BLURB HERE *** Jit Loon Lim (16): arch: arm: update kconfig for new platform agilex5 arch: arm: dts: add dts and dtsi for new platform agilex5 arch: arm: mach-socfpga: add new platform agilex5 mach-socfpga enablement arch: arm: mach-socfpga: include: mach: add new platform agilex5 mach-socfpga enablement board: intel: add new platform agilex5 socdk configs: add new platform agilex5 defconfig doc: device-tree-bindings: misc: add secreg text file for agilex5 drivers: ddr: altera: add ddr support for agilex5 drivers: clk: altera: add clock support for agilex5 drivers: misc: update driver misc for agilex5 drivers: mmc: add mmc/cadence driver for agilex5 drivers: phy: add combo phy driver for agilex5 drivers: reset: add reset driver for agilex5 drivers: sysreset: add system driver for agilex5 drivers: watchdog: update watchdog driver for agilex5 includes: add and update configuration for agilex5 Sieu Mun Tang (1): tools: binman: update binman tool for agilex5 arch/arm/Kconfig | 5 +- arch/arm/dts/Makefile | 1 + arch/arm/dts/socfpga_agilex5-u-boot.dtsi | 459 ++ arch/arm/dts/socfpga_agilex5.dtsi | 634 + .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 131 +++ arch/arm/dts/socfpga_agilex5_socdk.dts| 165 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi| 38 +- arch/arm/dts/socfpga_soc64_u-boot.dtsi| 120 +++ arch/arm/dts/socfpga_stratix10.dtsi | 0 .../dts/socfpga_stratix10_socdk-u-boot.dtsi | 0 arch/arm/dts/socfpga_stratix10_socdk.dts | 0 arch/arm/mach-socfpga/Kconfig | 92 ++ arch/arm/mach-socfpga/Makefile| 69 +- arch/arm/mach-socfpga/board.c | 65 +- arch/arm/mach-socfpga/clock_manager_agilex5.c | 82 ++ arch/arm/mach-socfpga/firewall.c | 107 --- .../include/mach/base_addr_soc64.h| 43 +- .../mach-socfpga/include/mach/clock_manager.h | 5 +- .../include/mach/clock_manager_agilex5.h | 12 + arch/arm/mach-socfpga/include/mach/firewall.h | 42 +- .../mach-socfpga/include/mach/handoff_soc64.h | 25 +- .../mach-socfpga/include/mach/mailbox_s10.h | 32 +- .../include/mach/reset_manager_soc64.h| 33 +- .../mach-socfpga/include/mach/smmu_agilex5.h | 30 + arch/arm/mach-socfpga/include/mach/smmu_s10.h | 73 ++ .../include/mach/system_manager_soc64.h | 126 ++- arch/arm/mach-socfpga/include/mach/timer.h| 30 + arch/arm/mach-socfpga/lowlevel_init_agilex5.S | 61 ++ arch/arm/mach-socfpga/lowlevel_init_soc64.S | 167 +++- arch/arm/mach-socfpga/mailbox_s10.c | 21 + arch/arm/mach-socfpga/misc.c | 19 +- arch/arm/mach-socfpga/misc_soc64.c| 33 +- arch/arm/mach-socfpga/mmu-arm64_s10.c | 43 +- arch/arm/mach-socfpga/reset_manager_s10.c | 271 +- arch/arm/mach-socfpga/secure_reg_helper.c | 4 +- arch/arm/mach-socfpga/smmu_agilex5.c | 34 + arch/arm/mach-socfpga/smmu_s10.c | 126 +++ arch/arm/mach-socfpga/spl_agilex5.c | 180 arch/arm/mach-socfpga/spl_soc64.c | 188 +++- arch/arm/mach-socfpga/u-boot-spl-soc64.lds| 93 ++ arch/arm/mach-socfpga/wrap_handoff_soc64.c| 7 +- board/intel/agilex5-socdk/MAINTAINERS | 8 + board/intel/agilex5-socdk/Makefile| 7 + board/intel/agilex5-socdk/socfpga.c | 7 + configs/socfpga_agilex5_defconfig | 125 +++ configs/socfpga_agilex5_legacy_defconfig | 87 ++ .../misc/socfpga_secreg.txt | 397 drivers/clk/altera/Makefile | 1 + drivers/clk/altera/clk-agilex5.c | 736 +++ drivers/clk/altera/clk-agilex5.h | 263 ++ drivers/ddr/altera/Makefile | 5 +- drivers/ddr/altera/iossm_mailbox.c| 786 drivers/ddr/altera/iossm_mailbox.h| 141 +++ drivers/ddr/altera/sdram_agilex5.c| 329 +++ drivers/ddr/altera/sdram_soc64.c | 78 +- drivers/ddr/altera/sdram_soc64.h | 17 +- drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/socfpga_secreg.c | 116 +++ drivers/mmc/mmc.c | 27 +- drivers/mmc/sdhci-cadence.c | 164 +++- drivers/phy/cadence/Kconfig | 9 + drivers/phy/cadence/Makefile | 1 + drivers/phy/cadence/phy-cadence-combophy.c| 855 ++ drivers/reset/reset-socfpga.c | 28 +- drivers/sys
[PATCH v3 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
From: Teik Heng Chong Fix the write to the HPRT register which treat W1C fields as if they were mere RW. This leads to unintended clearing of such fields This bug was found during the testing on Simics model. Referring to specification DesignWare Cores USB 2.0 Hi-Speed On-The-Go (OTG) Databook (3.30a)"5.3.4.8 Host Port Control and Status Register (HPRT)", the HPRT.PrtPwr is cleared by this mistake. In the Linux driver (contrary to U-Boot), HPRT is always read using dwc2_read_hprt0 helper function which clears W1C bits. So after write back those bits are zeroes. Signed-off-by: Teik Heng Chong --- V2->V3 - update commit message --- drivers/usb/host/dwc2.c | 34 -- drivers/usb/host/dwc2.h | 4 2 files changed, 12 insertions(+), 26 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..9818f9be94 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev, /* Turn on the vbus power. */ if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { - hprt0 = readl(®s->hprt0); - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET); - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG); + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { hprt0 |= DWC2_HPRT0_PRTPWR; writel(hprt0, ®s->hprt0); @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS: switch (wValue) { case USB_PORT_FEAT_C_CONNECTION: - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTCONNDET); break; } break; @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, break; case USB_PORT_FEAT_RESET: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_POWER: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_ENABLE: @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) dwc_otg_core_host_init(dev, regs); } - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET | -DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG | -DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); for (i = 0; i < MAX_DEVICE; i++) { for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) static void dwc2_uninit_common(struct dwc2_core_regs *regs) { /* Put everything in reset. */ - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); } #if !CONFIG_IS_ENABLED(DM_USB) diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index a6f562fe60..6f022e33a1 100644 --- a/drivers/usb/host/dwc2.h +++ b/drivers/usb/host/dwc2.h @@ -543,6 +543,10 @@ struct dwc2_core_regs { #define DWC2_HPRT0_PRTSPD_LOW
RE: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
> -Original Message- > From: Marek Vasut > Sent: Wednesday, 21 June, 2023 9:20 AM > To: Chong, Teik Heng ; u-boot@lists.denx.de > Cc: Jagan Teki ; Vignesh R > ; Simon ; Kris > ; Chee, Tien Fong ; Hea, > Kok Kiang ; Lokanathan, Raaj > ; Maniyam, Dinesh > ; Ng, Boon Khai ; > Yuslaimi, Alif Zakuan ; Zamri, Muhammad > Hazim Izzat ; Lim, Jit Loon > ; Tang, Sieu Mun ; > Patrice CHOTARD ; Patrick DELAUNAY > > Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT > register > > On 6/21/23 02:57, Chong, Teik Heng wrote: > > -Original Message- > > From: Marek Vasut > > Sent: Wednesday, 21 June, 2023 5:38 AM > > To: Chong, Teik Heng ; u-boot@lists.denx.de > > Cc: Jagan Teki ; Vignesh R > > ; Simon ; Kris > > ; Chee, Tien Fong ; > > Hea, Kok Kiang ; Lokanathan, Raaj > > ; Maniyam, Dinesh > > ; Ng, Boon Khai ; > > Yuslaimi, Alif Zakuan ; Zamri, > > Muhammad Hazim Izzat ; Lim, > Jit > > Loon ; Tang, Sieu Mun > > ; Patrice CHOTARD > > ; Patrick DELAUNAY > > > > Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in > > HPRT register > > > > On 6/20/23 15:52, teik.heng.ch...@intel.com wrote: > >> From: Teik Heng Chong > >> > >> Fix the write to the HPRT register which treat W1C fields as if they > >> were mere RW. This leads to unintended clearing of such fields > >> > >> Signed-off-by: Teik Heng Chong > >> > >> --- > >> > >> V1->V2 > >> - update subject tags to usb:dwc2 > >> --- > >>drivers/usb/host/dwc2.c | 34 -- > >>drivers/usb/host/dwc2.h | 4 > >>2 files changed, 12 insertions(+), 26 deletions(-) > >> > >> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index > >> 23060fc369..9818f9be94 100644 > >> --- a/drivers/usb/host/dwc2.c > >> +++ b/drivers/usb/host/dwc2.c > >> @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice > >> *dev, > >> > >>/* Turn on the vbus power. */ > >>if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { > >> - hprt0 = readl(®s->hprt0); > >> - hprt0 &= ~(DWC2_HPRT0_PRTENA | > DWC2_HPRT0_PRTCONNDET); > >> - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | > DWC2_HPRT0_PRTOVRCURRCHNG); > >> + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; > >>if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { > >>hprt0 |= DWC2_HPRT0_PRTPWR; > >>writel(hprt0, ®s->hprt0); > >> @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct > dwc2_priv *priv, > >>case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | > USB_TYPE_CLASS: > >>switch (wValue) { > >>case USB_PORT_FEAT_C_CONNECTION: > >> - setbits_le32(®s->hprt0, > DWC2_HPRT0_PRTCONNDET); > >> + clrsetbits_le32(®s->hprt0, > DWC2_HPRT0_W1C_MASK, > >> +DWC2_HPRT0_PRTCONNDET); > >>break; > >>} > >>break; > >> @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct > dwc2_priv *priv, > >>break; > >> > >>case USB_PORT_FEAT_RESET: > >> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA > | > >> - DWC2_HPRT0_PRTCONNDET | > >> - DWC2_HPRT0_PRTENCHNG | > >> - DWC2_HPRT0_PRTOVRCURRCHNG, > >> - DWC2_HPRT0_PRTRST); > >> + clrsetbits_le32(®s->hprt0, > DWC2_HPRT0_W1C_MASK, > >> +DWC2_HPRT0_PRTRST); > >>mdelay(50); > >> - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); > >> + clrbits_le32(®s->hprt0, > DWC2_HPRT0_W1C_MASK | > >> +DWC2_HPRT0_PRTRST); > >>break; > >> > >>case USB_PORT_FEAT_POWER: > >> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA > | > >> - DWC2_HPRT0_PRTCONNDET | > >> - DWC2_HPRT0_PRTENCHNG | > >> - DWC2_HPRT0_PRTOVRCURRCHNG, > >> - DWC2_HPRT0_PRTRST); > >> + clrsetbits_le32(®s->hprt0, > DWC2_HPRT0_W1C_MASK, > >> +DWC2_HPRT0_PRTRST); > >>break; > >> > >>case USB_PORT_FEAT_ENABLE: > >> @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice > *dev, struct dwc2_priv *priv) > >>dwc_otg_core_host_init(dev, regs); > >>} > >> > >> - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | > >> - DWC2_HPRT0_PRTCONNDET | > DWC2_HPRT0_PRTENCHNG | > >> - DWC2_HPRT0_PRTOVRCURRCHNG, > >> - DWC2_HPRT0_PRTRST); > >> + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, > >> +DWC2_HPRT0_PRTRST); > >>mdelay(50); > >> - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTE
Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM
> From: Yanhong Wang > Sent: Thursday, June 15, 2023 5:37 PM > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo > Yu-Chi Liang(梁育齊) ; Joe Hershberger > ; Ramon Fried > Cc: Yanhong Wang ; Torsten Duwe ; > Leyfoon Tan ; samin . guo > ; Walker Chen ; Hal > Feng > Subject: [PATCH v5 10/11] ram: starfive: Read memory size information from > EEPROM > > StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of DDR > capacity includes 2G/4G/8G, a DT can not support multiple capacities, so the > capacity size information is recorded to EEPROM, when DDR initialization > required capacity size information is read from EEPROM. > > If there is no information in EEPROM, it is initialized with the default size > defined in DT. > > Signed-off-by: Yanhong Wang > --- > arch/riscv/cpu/jh7110/spl.c | 32 - > drivers/ram/starfive/starfive_ddr.c | 2 -- > 2 files changed, 31 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c index > 104f0fe949..72adcefa0e 100644 > --- a/arch/riscv/cpu/jh7110/spl.c > +++ b/arch/riscv/cpu/jh7110/spl.c > @@ -3,19 +3,49 @@ > * Copyright (C) 2022 StarFive Technology Co., Ltd. > * Author: Yanhong Wang > */ > - > +#include > +#include > #include > #include > #include > +#include > #include > +#include > > #define CSR_U74_FEATURE_DISABLE0x7c1 > #define L2_LIM_MEM_END 0x81FUL > > +DECLARE_GLOBAL_DATA_PTR; > + > +static bool check_ddr_size(phys_size_t size) { > + switch (size) { > + case SZ_2: > + case SZ_4: > + case SZ_8: > + case SZ_16: In commit message, it describes that "DDR capacity includes 2G/4G/8G". Is it mismatch here ? > + return true; > + default: > + return false; > + } > +} > + > int spl_soc_init(void) > { > int ret; > struct udevice *dev; > + phys_size_t size; > + > + ret = fdtdec_setup_mem_size_base(); > + if (ret) > + return ret; It maybe unnecessary to add return above. If it fail to parse memory node from DT, then there has no chance to get ddr size from eeprom. Thanks, Rick > + > + /* Read the definition of the DDR size from eeprom, and if not, > +* use the definition in DT > +*/ > + size = (get_ddr_size_from_eeprom() >> 16) & 0xFF; > + if (check_ddr_size(size)) > + gd->ram_size = size << 30; > > /* DDR init */ > ret = uclass_get_device(UCLASS_RAM, 0, &dev); diff --git > a/drivers/ram/starfive/starfive_ddr.c b/drivers/ram/starfive/starfive_ddr.c > index 553f2ce6f4..a0a3d6b33d 100644 > --- a/drivers/ram/starfive/starfive_ddr.c > +++ b/drivers/ram/starfive/starfive_ddr.c > @@ -72,8 +72,6 @@ static int starfive_ddr_probe(struct udevice *dev) > u64 rate; > int ret; > > - /* Read memory base and size from DT */ > - fdtdec_setup_mem_size_base(); > priv->info.base = gd->ram_base; > priv->info.size = gd->ram_size; > > -- > 2.17.1
Re: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for 1.2A and 1.3B
> From: Yanhong Wang > Sent: Thursday, June 15, 2023 5:37 PM > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo > Yu-Chi Liang(梁育齊) ; Joe Hershberger > ; Ramon Fried > Cc: Yanhong Wang ; Torsten Duwe ; > Leyfoon Tan ; samin . guo > ; Walker Chen ; Hal > Feng > Subject: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for > 1.2A and 1.3B > > The main difference between StarFive VisionFive 2 1.2A and 1.3B is gmac. > You can read the PCB version of the current board by > get_pcb_revision_from_eeprom(), and then dynamically configure the difference > of gmac in spl_perform_fixups() according to different PCB versions, so that > one DT and one defconfig can support both 1.2A and 1.3B versions, which is > more user-friendly. > > Signed-off-by: Yanhong Wang > --- > board/starfive/visionfive2/spl.c | 157 +++ > 1 file changed, 157 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux
> From: Conor Dooley > Sent: Thursday, June 15, 2023 6:13 PM > To: u-boot@lists.denx.de > Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; Padmarao Begari ; > Conor Dooley > Subject: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux > > The "notable" disappearances are: > - the pac193x stanza - there's nothing in mainline linux w.r.t. bindings > for this & what is going to appear in mainline linux is going to be > incompatible with what is currently in U-Boot. > - operating points - these operating points should not be set at the > soc.dtsi level as they may not be possible depending on the design > programmed to the FPGA > - clock output names - there are defines for the clock indices, these > should not be needed > - the dt maintainers in linux NAKed using defines for IRQ numbers > - the qspi nand, which is not part of the icicle's default configuration > is removed. > > Reviewed-by: Padmarao Begari > Tested-by: Padmarao Begari > Signed-off-by: Conor Dooley > --- > arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi| 71 +++ > arch/riscv/dts/mpfs-icicle-kit.dts| 190 +--- > arch/riscv/dts/mpfs.dtsi | 442 -- > .../dt-bindings/clock/microchip-mpfs-clock.h | 29 +- > .../microchip-mpfs-plic.h | 196 > .../interrupt-controller/riscv-hart.h | 17 - Reviewed-by: Rick Chen
Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
On 6/21/23 02:57, Chong, Teik Heng wrote: -Original Message- From: Marek Vasut Sent: Wednesday, 21 June, 2023 5:38 AM To: Chong, Teik Heng ; u-boot@lists.denx.de Cc: Jagan Teki ; Vignesh R ; Simon ; Kris ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Zamri, Muhammad Hazim Izzat ; Lim, Jit Loon ; Tang, Sieu Mun ; Patrice CHOTARD ; Patrick DELAUNAY Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register On 6/20/23 15:52, teik.heng.ch...@intel.com wrote: From: Teik Heng Chong Fix the write to the HPRT register which treat W1C fields as if they were mere RW. This leads to unintended clearing of such fields Signed-off-by: Teik Heng Chong --- V1->V2 - update subject tags to usb:dwc2 --- drivers/usb/host/dwc2.c | 34 -- drivers/usb/host/dwc2.h | 4 2 files changed, 12 insertions(+), 26 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..9818f9be94 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev, /* Turn on the vbus power. */ if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { - hprt0 = readl(®s->hprt0); - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET); - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG); + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { hprt0 |= DWC2_HPRT0_PRTPWR; writel(hprt0, ®s->hprt0); @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS: switch (wValue) { case USB_PORT_FEAT_C_CONNECTION: - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTCONNDET); break; } break; @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, break; case USB_PORT_FEAT_RESET: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | +DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_POWER: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_ENABLE: @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) dwc_otg_core_host_init(dev, regs); } - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET | -DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG | -DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); for (i = 0; i < MAX_DEVICE; i++) { for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) static void dwc2_uninit_common(struct dwc2_core_regs *regs) { /* Put everything in reset. */ - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, +DWC2_HPRT0_PRTRST); } #if !CONFIG_IS_ENABLED(DM_USB) diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index a6f562fe60..6f022e33a1 100644 ---
RE: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
-Original Message- From: Marek Vasut Sent: Wednesday, 21 June, 2023 5:38 AM To: Chong, Teik Heng ; u-boot@lists.denx.de Cc: Jagan Teki ; Vignesh R ; Simon ; Kris ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Zamri, Muhammad Hazim Izzat ; Lim, Jit Loon ; Tang, Sieu Mun ; Patrice CHOTARD ; Patrick DELAUNAY Subject: Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register On 6/20/23 15:52, teik.heng.ch...@intel.com wrote: > From: Teik Heng Chong > > Fix the write to the HPRT register which treat W1C fields as if they > were mere RW. This leads to unintended clearing of such fields > > Signed-off-by: Teik Heng Chong > > --- > > V1->V2 > - update subject tags to usb:dwc2 > --- > drivers/usb/host/dwc2.c | 34 -- > drivers/usb/host/dwc2.h | 4 > 2 files changed, 12 insertions(+), 26 deletions(-) > > diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index > 23060fc369..9818f9be94 100644 > --- a/drivers/usb/host/dwc2.c > +++ b/drivers/usb/host/dwc2.c > @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice > *dev, > > /* Turn on the vbus power. */ > if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { > - hprt0 = readl(®s->hprt0); > - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET); > - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG); > + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; > if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { > hprt0 |= DWC2_HPRT0_PRTPWR; > writel(hprt0, ®s->hprt0); > @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv > *priv, > case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS: > switch (wValue) { > case USB_PORT_FEAT_C_CONNECTION: > - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET); > + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, > +DWC2_HPRT0_PRTCONNDET); > break; > } > break; > @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv > *priv, > break; > > case USB_PORT_FEAT_RESET: > - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | > - DWC2_HPRT0_PRTCONNDET | > - DWC2_HPRT0_PRTENCHNG | > - DWC2_HPRT0_PRTOVRCURRCHNG, > - DWC2_HPRT0_PRTRST); > + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, > +DWC2_HPRT0_PRTRST); > mdelay(50); > - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); > + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | > +DWC2_HPRT0_PRTRST); > break; > > case USB_PORT_FEAT_POWER: > - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | > - DWC2_HPRT0_PRTCONNDET | > - DWC2_HPRT0_PRTENCHNG | > - DWC2_HPRT0_PRTOVRCURRCHNG, > - DWC2_HPRT0_PRTRST); > + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, > +DWC2_HPRT0_PRTRST); > break; > > case USB_PORT_FEAT_ENABLE: > @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, > struct dwc2_priv *priv) > dwc_otg_core_host_init(dev, regs); > } > > - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | > - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | > - DWC2_HPRT0_PRTOVRCURRCHNG, > - DWC2_HPRT0_PRTRST); > + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, > +DWC2_HPRT0_PRTRST); > mdelay(50); > - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET | > - DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG | > - DWC2_HPRT0_PRTRST); > + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); > > for (i = 0; i < MAX_DEVICE; i++) { > for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ > static > int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) > static void dwc2_uninit_common(struct dwc2_core_regs *regs) > { > /* Put everything in reset. */ > - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | > - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | > - DWC2_HPRT0_PRTOVRCURRCHNG, > - DWC2_HPRT0_PRTRST); > + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, > +DWC2_HPRT0_PRTRST); > } > > #if !CONFIG_IS_ENABLED(DM_USB) > diff --git
[PATCH] arm: mvebu: Enable gpio-fan for Thecus N2350 board
Add gpio-fan in the DTS and enable the GPIO in board file to start the fan during boot. Note that this patch depends on https://patchwork.ozlabs.org/project/uboot/patch/20230606214539.4229-1-mibo...@gmail.com/ Signed-off-by: Tony Dinh --- arch/arm/dts/armada-385-thecus-n2350.dts | 15 +++ board/thecus/n2350/n2350.c | 2 +- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts b/arch/arm/dts/armada-385-thecus-n2350.dts index 2ad5158c0c..253cf01130 100644 --- a/arch/arm/dts/armada-385-thecus-n2350.dts +++ b/arch/arm/dts/armada-385-thecus-n2350.dts @@ -140,6 +140,16 @@ }; }; + fan { + compatible = "gpio-fan"; + gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; + gpio-fan,speed-map = <0 0 + 600 1 + 3000 2 >; + pinctrl-0 = <&pmx_fan>; + pinctrl-names = "default"; + }; + usb3_0_power: v5-vbus0 { compatible = "regulator-fixed"; regulator-name = "USB3_0_Power"; @@ -378,6 +388,11 @@ marvell,pins = "mpp17"; marvell,function = "gpio"; }; + + pmx_fan: pmx-fan { + marvell,pins = "mpp48"; + marvell,function = "gpio"; + }; }; &sdhci { diff --git a/board/thecus/n2350/n2350.c b/board/thecus/n2350/n2350.c index fd8f95f944..05b125fd7f 100644 --- a/board/thecus/n2350/n2350.c +++ b/board/thecus/n2350/n2350.c @@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR; #define N2350_GPP_OUT_ENA_LOW (~(BIT(20) | BIT(21) | BIT(24))) #define N2350_GPP_OUT_ENA_MID (~(BIT(12) | BIT(13) | BIT(16) | BIT(19) | BIT(22))) #define N2350_GPP_OUT_VAL_LOW (BIT(21) | BIT(24)) -#define N2350_GPP_OUT_VAL_MID (BIT(0) | BIT(12) | BIT(13)) +#define N2350_GPP_OUT_VAL_MID (BIT(0) | BIT(12) | BIT(13) | BIT(16)) #define N2350_GPP_POL_LOW 0x0 #define N2350_GPP_POL_MID 0x0 -- 2.39.2
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
On 6/20/23 12:43, Xavier Drudis Ferran wrote: El Tue, Jun 20, 2023 at 11:49:36AM +0200, Marek Vasut deia: Default, see: $ git grep CONFIG_BOOTCOMMAND configs/ I'm lost. I called default what Kconfig used as default. You seem to call default what's in board specific config files. Whatever. Fix the wording in the commit message if you like. All I am really asking for is minimal test case. That is all I was asking for since the very beginning. So to answer my own question, this is the minimal test case: => usb reset ; bootflow scan ; usb info Can you please add it to the commit message, collect RB from Simon, add Reviewed-by: Marek Vasut Tested-by: Marek Vasut And send V2 so I can pick it for this release ? Thank you
Re: imx8m optee load address?
On Mon, Jun 19, 2023 at 1:40 PM Tim Harvey wrote: > > On Fri, Jun 16, 2023 at 4:52 PM Tim Harvey wrote: > > > > On Thu, Jun 15, 2023 at 8:31 PM Peng Fan wrote: > > > > > > > > > > > > On 6/16/2023 9:56 AM, Tim Harvey wrote: > > > > Greetings, > > > > > > > > I've seen several IMX8M boards include a firmware/optee node in the > > > > U-Boot dt (git grep optee arch/arm/dts/imx8m*.dtsi) yet but none that > > > > I see configure binman to actually add the binary in the u-boot.dtsi, > > > > do anything to keep U-Boot from accessing the OPTEE memory, or > > > > document how to configure and build OPTEE for imx8m. I would like to > > > > add such support but I find it odd that OPTEE needs to be built > > > > differently depending on the dram size. > > > > > > > > Prior to switching to binman (v2021.10) > > > > arch/arm/mach-imx/mkimage_fit_atf.sh [1] would include tee.bin in the > > > > FIT image if it was found in the current directory and it was expected > > > > that you provide a proper TEE_LOAD_ADDR via the env (commit > > > > a9eed6e1b8d8 ("imx: imx8m: introduce script to generate fit image"). > > > > > > > > According to the IMX OPTEE documentation [2] the size and location of > > > > OPTEE is hard coded (CFG_TZDRAM_START and CFG_TZDRAM_SIZE) but looking > > > > at the imx-optee source [3] this is calculated based off of > > > > CFG_DDR_SIZE (which you can provide via env at build time or just > > > > provide CFG_TZDRAM_START and CFG_TZDRAM_SIZE via env directly). > > > > > > optee does not support PIE, it could only run at the address that built > > > time defined. > > > > Hi Peng, > > > > I wasn't thinking about PIE but just building it at a location other > > than the top of DRAM in order to come up with a generalized location > > instead of having to customize u-boot.dtsi for different RAM sizes and > > to workaround the 4GiB boundary issue. > > > > If my understanding is correct optee's load address needs to match between: > > 1. atf: BL32_BASE at build time defines the address in secure memory > > where BL2 loads the BL32 binary image (tee.bin) (must be aligned on a > > page-size boundary) > > 2. optee: CFG_TZDRAM_START at build time (calculated based off of > > CFG_DDR_SIZE) defines the address it is built to run at. Note you must > > still define CFG_DDR_SIZE properly as this is passed to > > imx_tzc_auto_configure() > > 3. uboot: tee.bin is contained in u-boot.itb FIT image and specifies > > the address that U-Boot SPL loads tee.bin into > > > > I'm really trying to understand the imx8m 4GiB limit issue as that > > seems to be a huge limiation. > > Peng, > > I've made good progress and now have a 4GiB imx8mm board working with > optee (with 1 hack): > > > > > On an imx8mm board with 4GiB of DRAM configured with > > atf:BL32_BASE=0x13e00 > > optee:CFG_DDR_SIZE=0x1,CFG_TZDRAM_START=0x13e00 and > > u-boot.dtsi tee.bin load/entry=<0x1 0x3e00> we get this: > > > > U-Boot SPL 2023.04-00027-g578c653cbafa (Jun 16 2023 - 09:22:40 -0700) > > GSCv3 : v58 0xf098 RST:VIN Thermal protection:disabled > > RTC : 1970-01-01 0:05:40 UTC > > Model : GW7201-01-EB > > Serial : 852455 > > MFGDate : 11-10-2020 > > PMIC: MP5416 (IMX8MM) > > DRAM: LPDDR4 4 GiB 3000MT/s 1500MHz > > WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout) > > Trying to boot from eMMC > > DTB : imx8mm-venice-gw72xx-0x > > Cannot use 64 bit addresses with SDMA > > ^^^ This is the imx mmc driver warning that it can't load data into > > dram across 32bit boundary > > > > Authenticate image from DDR location 0x401fcdc0... > > NOTICE: Do not release JR0 to NS as it can be used by HAB > > ERROR: mmap_add_region_check() failed. error -34 > > ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:793 > > BACKTRACE: START: assert > > 0: EL3: 0x9289cc > > 1: EL3: 0x929efc > > 2: EL3: 0x92469c > > 3: EL3: 0x9248f4 > > 4: EL3: 0x928850 > > 5: EL3: 0x927594 > > 6: EL3: 0x920128 > > 7: EL3: 0x7eb19c > > 8: EL3: 0x7f3de0 > > BACKTRACE: END: assert > > > > This is where the atf jumps to optee so I can understand why the above > > doesn't work as U-Boot can't load tee.bin from the FIT to 0x13e00 > > (not sure where it gets loaded... the 64bit address probably wraps). > > I've also tried setting CFG_CORE_LARGE_PHYS_ADDR=y and > > CFG_CORE_ARM64_PA_BITS=36 in optee as this is what the imx8mp-evk > > config with 6GiB does and it ended with the same result but I do > > notice that doing this changes the link address > > The issue above appears to be a result of not setting > CFG_CORE_LARGE_PHYS_ADDR=y and CFG_CORE_ARM64_PA_BITS=36 in optee when > CFG_DDR_SIZE exceeds 3GiB. > > > > > The imx8mp-evk has 6GiB of dram on it. Does NXP not have a solution > > for secure boot on boards with >3GiB of dram? Is there some support > > in their downstream U-Boot that I'm maybe missing? Personally I can't > > even get NXP's lf_v2022.04 u-boot branch to build flash.bin for > > imx8mp_evk so I can try it out. > > The
Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support
Hi Andre, On 6/20/23 06:42, Andre Przywara wrote: So yeah, the request of a "Enter FEL" command came up multiple times, but so far no one could be bothered to implement this properly. The idea would be to have a generic command (more like "fel-reset" than efex), and allow each SoC (family) to implement this differently, as every SoC requires something a bit different here (32-bit vs. 64-bit, having an RTC vs not, etc). If you could post your solution somewhere, we could start this effort. There was some patch for the H3 already, and it's relatively straight-forward on the newer SoCs (H616, IIRC), so if at least two popular, but different SoCs would be supported, we could make sure to have the right abstractions in place. I already have a "go_to_fel()" that does the right thing to enter FEL from the SPL; I would pretty much just need to introduce the following per-SoC(-family) functions: - bool sunxi_fel_flag_test(void) - void sunxi_fel_flag_clear(void) - void sunxi_fel_flag_set(void) The "fel-reset" command (which is easier to type than what I have, "run fel_do_enter") would then call sunxi_fel_flag_set() and initiate a reset, and the SPL's early init just has to do sunxi_fel_flag_test() -> sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough. Could you recommend to me a sufficiently different chip to test my abstractions against? Something ARMv8 and *without* RTC? I can then send in a series adding FEL support for that. (Also, did that H3 patch actually land? I didn't see anything but want to know if I should be refactoring my approach to extend what that H3 patch does or not.) Ah, depending on the BSP kernel is indeed quite bad. I wonder what features of the kernel you rely on that upstream does not have? Or is it more about the BMC userland parts that are married to the Allwinner kernel and its own interfaces? I don't fully know; getting the kernel back on mainline is, as I said, a push for another day. I'm very much making a point of not looking into it before the bootloader can be upgraded to something that isn't a crashy, hard-to-update, failure-prone mess. (I'm working in "biggest fire, first out" order.) That said, the first such dependent feature that leaps to mind is the AWNAND driver's CONFIG_AW_SPINAND_SIMULATE_MULTIPLANE, which logically interleaves pages of the NAND in a different ordering vs. what the physical NAND (and mainline's spi-nand driver) does. Alas this is a feature we're dependent on not because it provides benefits to our users (it does not, and in downstream discussions I've been soapboxing about how it's likely wearing down people's NANDs) but because the boards are flashed at the factory with this flag enabled so we need it set for the NAND to be accessible. We've experimented with reflashing the board with that flag disabled, but that has so far only resulted in corrupted flash. Hope is not lost, though, for I have a half-written tool which shows some promise in being able to "unscramble the egg" and migrate existing NANDs over to the correct layout. That should be sufficient to get mainline U-Boot (and Tina Linux with the flag disabled) working, but I have no idea about mainline Linux still: this would only peel back one layer of the onion, and I don't know whether the next obstacle will be easier, harder, or about the same difficulty. But it does mean that, for now, we're stuck with Tina Linux. Final DT is a noble goal, but in reality there will always be room for improvement and additions. So what we typically do is to start with a simple .dts for the kernel tree, describing the basic peripherals, and everything that already works and is not subject to debate. If in doubt, include a node, and we will comment. Could you prepare such a patch? The peripheral-describing .dts that I have is for Tina Linux, and uses incompatible compatibles (ha), includes, dt-bindings, temporary hacks while better driver support can be developed, and would otherwise not fly upstream. I can send it in *anyway* if for some reason you think that's a good idea, but I really don't see that as being anything other than a waste of time. As well, I can't write a fresh .dts for mainline (one more likely to be accepted on the list). A mainline kernel has never been booted on this board, so I would do no better at this than a kernel contributor selected at random. The best I can do now is write something that *looks* like the correct .dts. As I keep saying, that may change in the future. But the answer today is still "no, I cannot." This should not contradict any DT nodes that U-Boot uses, so it's not a double effort. True, in theory it *shouldn't* but in practice, I've found it does. One way I've been bitten is that the sunxi SPI driver in U-Boot doesn't support Quad-SPI, so if the DT says the SPI-NAND is connected with a bus width of 4, the SPI-NAND driver requests Quad-SPI transfers, but the SPI master driver has no idea tha
Re: [PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
On 6/20/23 15:52, teik.heng.ch...@intel.com wrote: From: Teik Heng Chong Fix the write to the HPRT register which treat W1C fields as if they were mere RW. This leads to unintended clearing of such fields Signed-off-by: Teik Heng Chong --- V1->V2 - update subject tags to usb:dwc2 --- drivers/usb/host/dwc2.c | 34 -- drivers/usb/host/dwc2.h | 4 2 files changed, 12 insertions(+), 26 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..9818f9be94 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev, /* Turn on the vbus power. */ if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { - hprt0 = readl(®s->hprt0); - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET); - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG); + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { hprt0 |= DWC2_HPRT0_PRTPWR; writel(hprt0, ®s->hprt0); @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS: switch (wValue) { case USB_PORT_FEAT_C_CONNECTION: - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTCONNDET); break; } break; @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, break; case USB_PORT_FEAT_RESET: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_POWER: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_ENABLE: @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) dwc_otg_core_host_init(dev, regs); } - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET | -DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG | -DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); for (i = 0; i < MAX_DEVICE; i++) { for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) static void dwc2_uninit_common(struct dwc2_core_regs *regs) { /* Put everything in reset. */ - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); } #if !CONFIG_IS_ENABLED(DM_USB) diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index a6f562fe60..6f022e33a1 100644 --- a/drivers/usb/host/dwc2.h +++ b/drivers/usb/host/dwc2.h @@ -543,6 +543,10 @@ struct dwc2_core_regs { #define DWC2_HPRT0_PRTSPD_LOW (2 << 17) #define DWC2_HPRT0_PRTSPD_MASK(0x3 << 17) #define DWC2_HPRT0_PRTSPD_OFFSET 17 +#define DWC2_HPRT0_W1C_MASK(DWC2_HPRT0_PRTCONNDET | \ + DWC2_HPRT0_PRTENA | \ + DWC2_HPRT0_PRTENCH
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On Tue, Jun 20, 2023 at 08:36:11AM +0200, Michal Simek wrote: > > > On 6/19/23 19:04, Eugen Hristev wrote: > > On 6/19/23 19:07, Marek Vasut wrote: > > > On 6/19/23 15:26, Eugen Hristev wrote: > > > > On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: > > > > > [ Felipe: Ported from Linux kernel commit > > > > > f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] > > > > > > > > > > According to Synopsys Databook, we shouldn't be relying on > > > > > GCTL.CORESOFTRESET bit as that's only for debugging purposes. > > > > > Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. > > > > > > > > > > Host side block will be reset by XHCI driver if necessary. Note that > > > > > this > > > > > reduces amount of time spent on dwc3_probe() by a long margin. > > > > > > > > > > We're still gonna wait for reset to finish for a long time > > > > > (default to 1ms max), but tests show that the reset polling loop > > > > > executed > > > > > at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 > > > > > times in a row). > > > > > > > > > > Without proper core reset, observing random issues like when the > > > > > USB(DWC3) is in device mode, the host device is not able to detect the > > > > > USB device. > > > > > > > > > > Signed-off-by: Venkatesh Yadav Abbarapu > > > > > --- > > > > > drivers/usb/dwc3/core.c | 50 > > > > > +++-- > > > > > 1 file changed, 18 insertions(+), 32 deletions(-) > > > > > > > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > > > > > index 49f6a1900b..8702a54efa 100644 > > > > > --- a/drivers/usb/dwc3/core.c > > > > > +++ b/drivers/usb/dwc3/core.c > > > > > @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 > > > > > mode) > > > > > static int dwc3_core_soft_reset(struct dwc3 *dwc) > > > > > { > > > > > u32 reg; > > > > > + int retries = 1000; > > > > > - /* Before Resetting PHY, put Core in Reset */ > > > > > - reg = dwc3_readl(dwc->regs, DWC3_GCTL); > > > > > - reg |= DWC3_GCTL_CORESOFTRESET; > > > > > - dwc3_writel(dwc->regs, DWC3_GCTL, reg); > > > > > - > > > > > - /* Assert USB3 PHY reset */ > > > > > - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); > > > > > - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; > > > > > - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); > > > > > - > > > > > - /* Assert USB2 PHY reset */ > > > > > - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); > > > > > - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; > > > > > - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); > > > > > - > > > > > - mdelay(100); > > > > > - > > > > > - /* Clear USB3 PHY reset */ > > > > > - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); > > > > > - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; > > > > > - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); > > > > > - > > > > > - /* Clear USB2 PHY reset */ > > > > > - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); > > > > > - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; > > > > > - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); > > > > > + /* > > > > > + * We're resetting only the device side because, if we're in > > > > > host mode, > > > > > + * XHCI driver will reset the host block. If dwc3 was configured > > > > > for > > > > > + * host-only mode, then we can return early. > > > > > + */ > > > > > + if (dwc->dr_mode == USB_DR_MODE_HOST) > > > > > + return 0; > > > > > - mdelay(100); > > > > > + reg = dwc3_readl(dwc->regs, DWC3_DCTL); > > > > > + reg |= DWC3_DCTL_CSFTRST; > > > > > + dwc3_writel(dwc->regs, DWC3_DCTL, reg); > > > > > - /* After PHYs are stable we can take Core out of reset state */ > > > > > - reg = dwc3_readl(dwc->regs, DWC3_GCTL); > > > > > - reg &= ~DWC3_GCTL_CORESOFTRESET; > > > > > - dwc3_writel(dwc->regs, DWC3_GCTL, reg); > > > > > + do { > > > > > + reg = dwc3_readl(dwc->regs, DWC3_DCTL); > > > > > + if (!(reg & DWC3_DCTL_CSFTRST)) > > > > > + return 0; > > > > > + udelay(1); > > > > > + } while (--retries); > > > > > - return 0; > > > > > + return -ETIMEDOUT; > > > > > } > > > > > /* > > > > > > > > Hello Venkatesh, Michal, > > > > > > > > I randomly found this patch while testing the Dwc3 on rockchip > > > > RK3588 , I noticed that you removed the code that resets the > > > > PHYs in this patch hence DWC3 is no longer starting in my case. > > > > Was this intentional with this patch ? > > > > > > All of these patches are NAK until the DWC3 is synchronized with > > > Linux. Picking random DWC3 patches and ignoring other fixes will > > > turn the whole driver into an unmaintainable mess and make the sync > > > that much harder in the future. I spent enormous amount of my spare > > > time trying to explain to Xilinx how to do that mostly > > > automatically, but that was all ignored or countered with reason > > > af
Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION
On Tuesday, June 20, 2023 4:03:18 P.M. EDT Marek Vasut wrote: > On 6/20/23 19:49, Detlev Casanova wrote: > > On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote: > >> On 6/19/23 20:27, Detlev Casanova wrote: > >>> On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote: > On 6/19/23 16:42, Detlev Casanova wrote: > > On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote: > >> On 6/16/23 17:21, Detlev Casanova wrote: > >>> Expose that information to the command shell to let scripts select > >>> the > >>> correct devicetree name. > >>> > >>> Signed-off-by: Detlev Casanova > >>> --- > >>> > >>> drivers/sysinfo/rcar3.c | 46 > >>> - > >>> 1 file changed, 36 insertions(+), 10 deletions(-) > >>> > >>> diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c > >>> index 7b127986da7..89ad46c5422 100644 > >>> --- a/drivers/sysinfo/rcar3.c > >>> +++ b/drivers/sysinfo/rcar3.c > >>> @@ -32,6 +32,8 @@ > >>> > >>> */ > >>> > >>> struct sysinfo_rcar_priv { > >>> > >>> charboardmodel[64]; > >>> > >>> + u8 id; > >>> + charrevision[4]; > >>> > >>> u8 val; > >>> > >>> }; > >>> > >>> @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice > >>> *dev, > >>> int id, size_t size, char *> > >>> > >>> switch (id) { > >>> > >>> case SYSINFO_ID_BOARD_MODEL: > >>> - strncpy(val, priv->boardmodel, size); > >>> - val[size - 1] = '\0'; > >>> + strlcpy(val, priv->boardmodel, size); > >>> + break; > >>> + case SYSINFO_ID_BOARD_REVISION: > >>> + strlcpy(val, priv->revision, size); > >>> + break; > >>> + default: > >>> + return -EINVAL; > >>> + }; > >>> + > >>> + val[size - 1] = '\0'; > >>> + return 0; > >>> +} > >>> + > >>> +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int > >>> *val) > >>> +{ > >>> + struct sysinfo_rcar_priv *priv = dev_get_priv(dev); > >>> + > >>> + switch (id) { > >>> + case SYSINFO_ID_BOARD_ID: > >>> + *val = priv->id; > >>> > >>> return 0; > >> > >> Why not return SYSINFO_ID_BOARD_REVISION as integer here ? > > > > Because the revision (on r-car3 boards at least) is in the format X.Y. > > It > > could be returned as "(X << 8) | Y" or split in major/minor. But > > different > > boards will use different revisions and I think that having a str is > > easier to deal with in a shell script. > > With rcar they are numbers, so lets go with major/minor integers > please. > >>> > >>> Ok for this part, but shouldn't the sysinfo command use a common > >>> interface > >>> for all boards ? Or should it also have rev_major/rev_minor arguments ? > >> > >> I would expect other boards to either report rev_major/rev_minor if > >> implemented, or errno if those boards don't implement this property. > > > > Another thing on rcar is that the revision is stored as 2 char values. > > Would you oppose a change form using a char (e.g. rev_major = '1') to > > using u8 values (e.g. rev_major = 1) instead ? > > Shouldn't those rev fields just be integer(s) to cover the generic case? On rcar, they are chars. I don't really see a reason for this except to show the '?.?' on unknown board ids. But that can be managed in other ways.
Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION
On 6/20/23 19:49, Detlev Casanova wrote: On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote: On 6/19/23 20:27, Detlev Casanova wrote: On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote: On 6/19/23 16:42, Detlev Casanova wrote: On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote: On 6/16/23 17:21, Detlev Casanova wrote: Expose that information to the command shell to let scripts select the correct devicetree name. Signed-off-by: Detlev Casanova --- drivers/sysinfo/rcar3.c | 46 - 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c index 7b127986da7..89ad46c5422 100644 --- a/drivers/sysinfo/rcar3.c +++ b/drivers/sysinfo/rcar3.c @@ -32,6 +32,8 @@ */ struct sysinfo_rcar_priv { char boardmodel[64]; + u8 id; + charrevision[4]; u8 val; }; @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice *dev, int id, size_t size, char *> switch (id) { case SYSINFO_ID_BOARD_MODEL: - strncpy(val, priv->boardmodel, size); - val[size - 1] = '\0'; + strlcpy(val, priv->boardmodel, size); + break; + case SYSINFO_ID_BOARD_REVISION: + strlcpy(val, priv->revision, size); + break; + default: + return -EINVAL; + }; + + val[size - 1] = '\0'; + return 0; +} + +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int *val) +{ + struct sysinfo_rcar_priv *priv = dev_get_priv(dev); + + switch (id) { + case SYSINFO_ID_BOARD_ID: + *val = priv->id; return 0; Why not return SYSINFO_ID_BOARD_REVISION as integer here ? Because the revision (on r-car3 boards at least) is in the format X.Y. It could be returned as "(X << 8) | Y" or split in major/minor. But different boards will use different revisions and I think that having a str is easier to deal with in a shell script. With rcar they are numbers, so lets go with major/minor integers please. Ok for this part, but shouldn't the sysinfo command use a common interface for all boards ? Or should it also have rev_major/rev_minor arguments ? I would expect other boards to either report rev_major/rev_minor if implemented, or errno if those boards don't implement this property. Another thing on rcar is that the revision is stored as 2 char values. Would you oppose a change form using a char (e.g. rev_major = '1') to using u8 values (e.g. rev_major = 1) instead ? Shouldn't those rev fields just be integer(s) to cover the generic case?
[PATCH] doc: statistics: Re-generate the last 3 releases
With some changes to our mapping files in gitdm, re-generate the last few releases worth of statistics to correctly reflect contributions. We only go back this far to try and find a balance between highlighting contributions and still being reviewable. Signed-off-by: Tom Rini --- .../statistics/u-boot-stats-v2022.10.rst | 27 +- .../statistics/u-boot-stats-v2023.01.rst | 52 ++- .../statistics/u-boot-stats-v2023.04.rst | 27 +- 3 files changed, 54 insertions(+), 52 deletions(-) diff --git a/doc/develop/statistics/u-boot-stats-v2022.10.rst b/doc/develop/statistics/u-boot-stats-v2022.10.rst index 6fb71d4753e8..7a5fc2edc7c2 100644 --- a/doc/develop/statistics/u-boot-stats-v2022.10.rst +++ b/doc/develop/statistics/u-boot-stats-v2022.10.rst @@ -607,20 +607,21 @@ Release Statistics for U-Boot v2022.10 = Name Count = - (Unknown) 590 (38.8%) + (Unknown) 584 (38.4%) Konsulko Group265 (17.4%) Google, Inc. 141 (9.3%) NXP 77 (5.1%) + AMD 70 (4.6%) ST Microelectronics 67 (4.4%) Linaro60 (3.9%) Texas Instruments 56 (3.7%) - AMD 53 (3.5%) DENX Software Engineering 45 (3.0%) Toradex 45 (3.0%) Weidmüller Interface GmbH & Co. KG41 (2.7%) - Xilinx29 (1.9%) Amarula Solutions 18 (1.2%) + Xilinx12 (0.8%) ARM 11 (0.7%) + Collabora Ltd.7 (0.5%) BayLibre SAS 5 (0.3%) SUSE 4 (0.3%) Socionext Inc.3 (0.2%) @@ -628,7 +629,6 @@ Release Statistics for U-Boot v2022.10 IBM 2 (0.1%) Siemens 2 (0.1%) Broadcom 1 (0.1%) - Collabora Ltd.1 (0.1%) Debian.org1 (0.1%) Marvell 1 (0.1%) Samsung 1 (0.1%) @@ -642,7 +642,7 @@ Release Statistics for U-Boot v2022.10 Name Count = Konsulko Group98915 (47.3%) - (Unknown) 36773 (17.6%) + (Unknown) 36630 (17.5%) Toradex 20197 (9.7%) NXP 11759 (5.6%) Google, Inc. 8739 (4.2%) @@ -651,12 +651,13 @@ Release Statistics for U-Boot v2022.10 Texas Instruments 5930 (2.8%) ST Microelectronics 3803 (1.8%) DENX Software Engineering 3551 (1.7%) - AMD 2343 (1.1%) + AMD 2591 (1.2%) Amarula Solutions 1360 (0.7%) - Xilinx1016 (0.5%) + Xilinx768 (0.4%) Broadcom 315 (0.2%) ARM 298 (0.1%) BayLibre SAS 197 (0.1%) + Collabora Ltd.144 (0.1%) SUSE 79 (0.0%) IBM 34 (0.0%) Bootlin 32 (0.0%) @@ -665,7 +666,6 @@ Release Statistics for U-Boot v2022.10 Debian.org4 (0.0%) Marvell 3 (0.0%) Samsung 2 (0.0%) - Collabora Ltd.1 (0.0%) = @@ -677,13 +677,14 @@ Release Statistics for U-Boot v2022.10 = AMD 81 (30.5%) NXP 51 (19.2%) - (Unknown) 33 (12.4%) + (Unknown) 28 (10.5%) Texas Instruments 19 (7.1%) Linaro16 (6.0%) ARM 16 (6.0%) Amarula Solutions 14 (5.3%) Xilinx13 (4.9%) Konsulko Group6 (2.3%) + Canonical 5 (1.9%) Toradex 4 (1.5%) Google, Inc. 4 (1.5%) Socionext Inc.
Re: [PATCH] rockchip: Pinebook Pro: Fix emmc default configuration
On 2023-05-01, Wolfgang Zarre wrote: > If u-boot is installed on the internal emmc, then this will > allow to boot without failure. > > Signed-off-by: Wolfgang Zarre > Reviewed-by: Kever Yang This is marked as accepted in patchwork, but I do not see it in git yet... Is this planned to land in 2023.07(-rc5?)? Thanks! live well, vagrant > configs/pinebook-pro-rk3399_defconfig | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/configs/pinebook-pro-rk3399_defconfig > b/configs/pinebook-pro-rk3399_defconfig > index dff4695e37..58a8b91aa6 100644 > --- a/configs/pinebook-pro-rk3399_defconfig > +++ b/configs/pinebook-pro-rk3399_defconfig > @@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x0020 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 > +CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_ENV_SIZE=0x8000 > CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro" > @@ -18,6 +19,7 @@ CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > +CONFIG_PCI=y > CONFIG_DEBUG_UART=y > CONFIG_BOOTDELAY=3 > CONFIG_USE_PREBOOT=y > @@ -57,17 +59,23 @@ CONFIG_LED=y > CONFIG_LED_GPIO=y > CONFIG_MISC=y > CONFIG_ROCKCHIP_EFUSE=y > +CONFIG_MMC_IO_VOLTAGE=y > +CONFIG_SPL_MMC_IO_VOLTAGE=y > +CONFIG_MMC_UHS_SUPPORT=y > +CONFIG_SPL_MMC_UHS_SUPPORT=y > +CONFIG_MMC_HS400_ES_SUPPORT=y > +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y > +CONFIG_MMC_HS400_SUPPORT=y > +CONFIG_SPL_MMC_HS400_SUPPORT=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_ROCKCHIP=y > CONFIG_SF_DEFAULT_BUS=1 > -CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_SPI_FLASH_GIGADEVICE=y > CONFIG_SPI_FLASH_WINBOND=y > CONFIG_NVME_PCI=y > -CONFIG_PCI=y > CONFIG_PHY_ROCKCHIP_INNO_USB2=y > CONFIG_PHY_ROCKCHIP_TYPEC=y > CONFIG_DM_PMIC_FAN53555=y signature.asc Description: PGP signature
[PATCH] mailbox: k3-sec-proxy: Fill non-message tx data fields with 0x0
Sec proxy data buffer is 60 bytes with the last of the registers indicating transmission completion. This however poses a bit of a challenge. The backing memory for sec_proxy is regular memory, and all sec proxy does is to trigger a burst of all 60 bytes of data over to the target thread backing ring accelerator. It doesn't do a memory scrub when it moves data out in the burst. When we transmit multiple messages, remnants of previous message is also transmitted which results in some random data being set in TISCI fields of messages that have been expanded forward. The entire concept of backward compatibility hinges on the fact that the unused message fields remain 0x0 allowing for 0x0 value to be specially considered when backward compatibility of message extension is done. So, instead of just writing the completion register, we continue to fill the message buffer up with 0x0 (note: for partial message involving completion, we already do this). This allows us to scale and introduce ABI changes back also work with other boot stages that may have left data in the internal memory. While at this, drop the unused accessor function. Fixes: f9aa41023bd9 ("mailbox: Introduce K3 Secure Proxy Driver") Signed-off-by: Nishanth Menon --- drivers/mailbox/k3-sec-proxy.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/mailbox/k3-sec-proxy.c b/drivers/mailbox/k3-sec-proxy.c index a862e55bc391..815808498f2e 100644 --- a/drivers/mailbox/k3-sec-proxy.c +++ b/drivers/mailbox/k3-sec-proxy.c @@ -94,11 +94,6 @@ static inline u32 sp_readl(void __iomem *addr, unsigned int offset) return readl(addr + offset); } -static inline void sp_writel(void __iomem *addr, unsigned int offset, u32 data) -{ - writel(data, addr + offset); -} - /** * k3_sec_proxy_of_xlate() - Translation of phandle to channel * @chan: Mailbox channel @@ -241,15 +236,20 @@ static int k3_sec_proxy_send(struct mbox_chan *chan, const void *data) /* Ensure all unused data is 0 */ data_trail &= 0x >> (8 * (sizeof(u32) - trail_bytes)); writel(data_trail, data_reg); - data_reg++; + data_reg += sizeof(u32); } /* * 'data_reg' indicates next register to write. If we did not already * write on tx complete reg(last reg), we must do so for transmit +* In addition, we also need to make sure all intermediate data +* registers(if any required), are reset to 0 for TISCI backward +* compatibility to be maintained. */ - if (data_reg <= (spt->data + spm->desc->data_end_offset)) - sp_writel(spt->data, spm->desc->data_end_offset, 0); + while (data_reg <= (spt->data + spm->desc->data_end_offset)) { + writel(0x0, data_reg); + data_reg += sizeof(u32); + } debug("%s: Message successfully sent on thread %ld\n", __func__, chan->id); -- 2.40.0
Re: [PATCH] usb: eth: lan78xx: Fix logic in lan78xx_read_otp() to avoid a warning
On Thu, 04 Jun 2020 16:35:15 -0400, Tom Rini wrote: > In lan78xx_read_otp() we want to know if sig is LAN78XX_OTP_INDICATOR_1 > or LAN78XX_OTP_INDICATOR_2. In the case of matching the first one we > set offset to itself, and clang warns about this. Rework the logic so > that if sig is the second indicator we adjust the offset as today and if > it does not match the first indicator we return -EINVAL > > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] spl: spl-nor: return error if no valid image was loaded
On Mon, 30 Jan 2023 10:21:43 +0100, Mario Kicherer wrote: > If only FIT images are enabled and loading the FIT image fails, > spl_nor_load_image() should return an error instead of zero. > > Without this patch: > > >>SPL: board_init_r() > spl_init > Trying to boot from NOR > Unsupported OS image.. Jumping nevertheless.. > image entry point: 0x0 > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v1 3/4] sysinfo: rcar3: Implement BOARD_ID and BOARD_REVISION
On Monday, June 19, 2023 5:54:44 P.M. EDT Marek Vasut wrote: > On 6/19/23 20:27, Detlev Casanova wrote: > > On Monday, June 19, 2023 12:11:18 P.M. EDT Marek Vasut wrote: > >> On 6/19/23 16:42, Detlev Casanova wrote: > >>> On Friday, June 16, 2023 8:43:33 P.M. EDT Marek Vasut wrote: > On 6/16/23 17:21, Detlev Casanova wrote: > > Expose that information to the command shell to let scripts select the > > correct devicetree name. > > > > Signed-off-by: Detlev Casanova > > --- > > > > drivers/sysinfo/rcar3.c | 46 > > - > > 1 file changed, 36 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c > > index 7b127986da7..89ad46c5422 100644 > > --- a/drivers/sysinfo/rcar3.c > > +++ b/drivers/sysinfo/rcar3.c > > @@ -32,6 +32,8 @@ > > > > */ > > > > struct sysinfo_rcar_priv { > > > > charboardmodel[64]; > > > > + u8 id; > > + charrevision[4]; > > > > u8 val; > > > > }; > > > > @@ -48,17 +50,37 @@ static int sysinfo_rcar_get_str(struct udevice > > *dev, > > int id, size_t size, char *> > > > > switch (id) { > > > > case SYSINFO_ID_BOARD_MODEL: > > - strncpy(val, priv->boardmodel, size); > > - val[size - 1] = '\0'; > > + strlcpy(val, priv->boardmodel, size); > > + break; > > + case SYSINFO_ID_BOARD_REVISION: > > + strlcpy(val, priv->revision, size); > > + break; > > + default: > > + return -EINVAL; > > + }; > > + > > + val[size - 1] = '\0'; > > + return 0; > > +} > > + > > +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int > > *val) > > +{ > > + struct sysinfo_rcar_priv *priv = dev_get_priv(dev); > > + > > + switch (id) { > > + case SYSINFO_ID_BOARD_ID: > > + *val = priv->id; > > > > return 0; > > Why not return SYSINFO_ID_BOARD_REVISION as integer here ? > >>> > >>> Because the revision (on r-car3 boards at least) is in the format X.Y. > >>> It > >>> could be returned as "(X << 8) | Y" or split in major/minor. But > >>> different > >>> boards will use different revisions and I think that having a str is > >>> easier to deal with in a shell script. > >> > >> With rcar they are numbers, so lets go with major/minor integers please. > > > > Ok for this part, but shouldn't the sysinfo command use a common interface > > for all boards ? Or should it also have rev_major/rev_minor arguments ? > I would expect other boards to either report rev_major/rev_minor if > implemented, or errno if those boards don't implement this property. Another thing on rcar is that the revision is stored as 2 char values. Would you oppose a change form using a char (e.g. rev_major = '1') to using u8 values (e.g. rev_major = 1) instead ?
Re: [PATCH 1/3] binman: Allow to define custom arguments
Hi Jan, On Tue, 20 Jun 2023 at 18:05, Jan Kiszka wrote: > > On 20.06.23 16:36, Simon Glass wrote: > > Hi Jan, > > > > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka wrote: > >> > >> On 20.06.23 12:11, Simon Glass wrote: > >>> Hi Jan, > >>> > >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: > > On 19.06.23 16:09, Simon Glass wrote: > > Hi Jan, > > > > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: > >> > >> On 19.06.23 14:36, Simon Glass wrote: > >>> Hi Jan, > >>> > >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka > >>> wrote: > > On 15.06.23 13:46, Jan Kiszka wrote: > > On 15.06.23 13:38, Simon Glass wrote: > >> Hi Jan, > >> > >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka > >> wrote: > >>> > >>> On 15.06.23 13:19, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:09, Jan Kiszka > wrote: > > > > On 15.06.23 12:55, Simon Glass wrote: > >> Hi Jan, > >> > >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka > >> wrote: > >>> > >>> On 12.06.23 23:17, Simon Glass wrote: > Hi Jan, > > On Mon, 5 Jun 2023 at 15:39, Jan Kiszka > wrote: > > > > From: Jan Kiszka > > > > Introduce BINMAN_EXTRA_ARGS that can be set per board, > > e.g., to inject > > specific settings. Will be used by IOT2050 first to define > > multiple > > of-lists. > > > > Signed-off-by: Jan Kiszka > > --- > > CC: Simon Glass > > --- > > Makefile | 1 + > > 1 file changed, 1 insertion(+) > > I'm really not keen on this, since it means that the > Makefile (or some > vars it sets) are again involved in controlling the image > generation. > It should really all be in the binman image description / > .dtsi file > >>> > >>> binman does not allow me to unrole of-list inside the dts > >>> file, does it? > >>> With such a feature, I wouldn't need any custom -a of-list-X > >>> switches > >>> and, thus, no such EXTRA_ARGS. > >> > >> Can you explain a bit more about what you mean by 'unrole'? It > >> is just > >> software, so anything should be possible. > > > > To use a DT sequence, I need to specify fit,ftd-list. But I can > > say > > > > fit,ftd-list = "first.dtb second.dtb" > > > > I rather need to go via the EntryArg indirection of the binman > > command line. > > Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are > you > wanting to filter that list based on something else? > > I'm afraid I am really not following this at all. > >>> > >>> CONFIG_OF_LIST is not working here as we have two different > >>> boards with > >>> two different lists. > >> > >> But we only build one board at a time, don't we? > > > > No, this is about building two flash images for two different board > > generations in the same binman run (see patch 3). > > > >> > >> We could provide a way to select between different lists, but how > >> does > >> Makefile get access to them? > > > > See patch 3: known lists, now put into board config.mk. > > > > Any better suggestions for this issue? Otherwise, I will have to keep > binman args extension for now. > >>> > >>> I've dug into this a bit. The use of #defines and macros looks to be > >>> unnecessary, unless I am missing something. > >>> > >>> You can do things like this: > >>> > >>> fit_node: fit { > >>> // base definition of FIT > >>> }; > >>> > >>> the later on: > >>> > >>> fit_node: { > >>> #ifdef xxx > >>>// override a few things > >>>fit,fdt-list = ... > >>> #else > >>> > >>> #endif > >> > >> As I wrote already, I have a solution for that by using a template > >> dtsi. > >> > >>> > >>> There is no need to specify the properties all at once. You can update > >>> a property later on just by referring to its node as above. > >> > >> Does not help when the anchor name needs to vary as well. That's where > >> I > >> will use a #define to
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 20.06.23 16:36, Simon Glass wrote: > Hi Jan, > > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka wrote: >> >> On 20.06.23 12:11, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: On 19.06.23 16:09, Simon Glass wrote: > Hi Jan, > > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: >> >> On 19.06.23 14:36, Simon Glass wrote: >>> Hi Jan, >>> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: On 15.06.23 13:46, Jan Kiszka wrote: > On 15.06.23 13:38, Simon Glass wrote: >> Hi Jan, >> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka >> wrote: >>> >>> On 15.06.23 13:19, Simon Glass wrote: Hi Jan, On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: > > On 15.06.23 12:55, Simon Glass wrote: >> Hi Jan, >> >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >> wrote: >>> >>> On 12.06.23 23:17, Simon Glass wrote: Hi Jan, On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: > > From: Jan Kiszka > > Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., > to inject > specific settings. Will be used by IOT2050 first to define > multiple > of-lists. > > Signed-off-by: Jan Kiszka > --- > CC: Simon Glass > --- > Makefile | 1 + > 1 file changed, 1 insertion(+) I'm really not keen on this, since it means that the Makefile (or some vars it sets) are again involved in controlling the image generation. It should really all be in the binman image description / .dtsi file >>> >>> binman does not allow me to unrole of-list inside the dts file, >>> does it? >>> With such a feature, I wouldn't need any custom -a of-list-X >>> switches >>> and, thus, no such EXTRA_ARGS. >> >> Can you explain a bit more about what you mean by 'unrole'? It >> is just >> software, so anything should be possible. > > To use a DT sequence, I need to specify fit,ftd-list. But I can > say > > fit,ftd-list = "first.dtb second.dtb" > > I rather need to go via the EntryArg indirection of the binman > command line. Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you wanting to filter that list based on something else? I'm afraid I am really not following this at all. >>> >>> CONFIG_OF_LIST is not working here as we have two different boards >>> with >>> two different lists. >> >> But we only build one board at a time, don't we? > > No, this is about building two flash images for two different board > generations in the same binman run (see patch 3). > >> >> We could provide a way to select between different lists, but how >> does >> Makefile get access to them? > > See patch 3: known lists, now put into board config.mk. > Any better suggestions for this issue? Otherwise, I will have to keep binman args extension for now. >>> >>> I've dug into this a bit. The use of #defines and macros looks to be >>> unnecessary, unless I am missing something. >>> >>> You can do things like this: >>> >>> fit_node: fit { >>> // base definition of FIT >>> }; >>> >>> the later on: >>> >>> fit_node: { >>> #ifdef xxx >>>// override a few things >>>fit,fdt-list = ... >>> #else >>> >>> #endif >> >> As I wrote already, I have a solution for that by using a template dtsi. >> >>> >>> There is no need to specify the properties all at once. You can update >>> a property later on just by referring to its node as above. >> >> Does not help when the anchor name needs to vary as well. That's where I >> will use a #define to customize the template on include. >> >>> >>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS >>> and all the #define stuff. >> >> You still didn't address my question. Should I share my version to make >> the problem clearer? But I thought I explained this in various shades >> already. > > Yes, if I am
Re: [PATCH 3/3] arm: dts: imx8mn: protect the firmware/optee node with ifdef
On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey wrote: > > There is no need to include the firmware/optee node if the optee > driver is not enabled. > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
Re: [PATCH 2/3] arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi
On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey wrote: > > Move the firmware/optee node to the common imx8mp-u-boot.dtsi and > protect it with an ifdef CONFIG_OPTEE as it is a meaningless node > without the optee driver enabled. > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
Re: [PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi
On Tue, Jun 20, 2023 at 12:19 PM Tim Harvey wrote: > > Move the firmware/optee node to the common imx8mm-u-boot.dtsi and > protect it with an ifdef CONFIG_OPTEE as it is a meaningless node > without the optee driver enabled. > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
[PATCH 3/3] arm: dts: imx8mn: protect the firmware/optee node with ifdef
There is no need to include the firmware/optee node if the optee driver is not enabled. Signed-off-by: Tim Harvey --- arch/arm/dts/imx8mn-u-boot.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi index cef20dab4688..8191b973b464 100644 --- a/arch/arm/dts/imx8mn-u-boot.dtsi +++ b/arch/arm/dts/imx8mn-u-boot.dtsi @@ -8,12 +8,14 @@ multiple-images; }; +#ifdef CONFIG_OPTEE firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; +#endif wdt-reboot { compatible = "wdt-reboot"; -- 2.25.1
[PATCH 2/3] arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi
Move the firmware/optee node to the common imx8mp-u-boot.dtsi and protect it with an ifdef CONFIG_OPTEE as it is a meaningless node without the optee driver enabled. Signed-off-by: Tim Harvey --- arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi | 7 --- arch/arm/dts/imx8mp-evk-u-boot.dtsi | 6 -- arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi | 7 --- arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi | 7 --- arch/arm/dts/imx8mp-u-boot.dtsi | 9 + arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi| 7 --- arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi | 7 --- 7 files changed, 9 insertions(+), 41 deletions(-) diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi index 5ca631e9d8c4..bb0f9bd0c8d3 100644 --- a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi @@ -11,13 +11,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &{/soc@0/bus@3080/i2c@30a2/pmic@25} { diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi b/arch/arm/dts/imx8mp-evk-u-boot.dtsi index 6784ed2e7c92..17965c58ba10 100644 --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi @@ -11,12 +11,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; ®_usdhc2_vmmc { diff --git a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi index d411cf79e85d..fe20938af536 100644 --- a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi @@ -12,13 +12,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; ®_usdhc2_vmmc { diff --git a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi index f3fb44046d5c..8f1df232b1b7 100644 --- a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi @@ -12,13 +12,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &iomuxc { diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi index 18d1728e1d2a..e8fe92485cd1 100644 --- a/arch/arm/dts/imx8mp-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-u-boot.dtsi @@ -8,6 +8,15 @@ binman: binman { multiple-images; }; + +#ifdef CONFIG_OPTEE + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + }; +#endif }; &soc { diff --git a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi index c3fb040080b6..44ac315a1241 100644 --- a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mp-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; diff --git a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi index 9c6c417f7eea..a985645ff8c3 100644 --- a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mp-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; -- 2.25.1
[PATCH 1/3] arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi
Move the firmware/optee node to the common imx8mm-u-boot.dtsi and protect it with an ifdef CONFIG_OPTEE as it is a meaningless node without the optee driver enabled. Signed-off-by: Tim Harvey --- arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 7 --- arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 7 --- arch/arm/dts/imx8mm-evk-u-boot.dtsi | 7 --- arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi | 7 --- arch/arm/dts/imx8mm-phg-u-boot.dtsi | 7 --- arch/arm/dts/imx8mm-u-boot.dtsi | 9 + arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi | 7 --- 7 files changed, 9 insertions(+), 42 deletions(-) diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi index 484e31824b85..d12ce6069cc7 100644 --- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mm-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi index 1878c4e13fbe..219504f61105 100644 --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mm-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-u-boot.dtsi index 13688ec0d0f2..155670da18d1 100644 --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi @@ -11,13 +11,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &aips4 { diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi index 65dfd33725ee..1ad9d49a1118 100644 --- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi @@ -16,13 +16,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &crypto { diff --git a/arch/arm/dts/imx8mm-phg-u-boot.dtsi b/arch/arm/dts/imx8mm-phg-u-boot.dtsi index 3ced97cfaafa..c9e0b4420500 100644 --- a/arch/arm/dts/imx8mm-phg-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-phg-u-boot.dtsi @@ -11,13 +11,6 @@ wdt = <&wdog1>; bootph-pre-ram; }; - - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; }; &aips4 { diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi index 7fd5a05fad3c..c48b5f2ef026 100644 --- a/arch/arm/dts/imx8mm-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-u-boot.dtsi @@ -7,6 +7,15 @@ binman: binman { multiple-images; }; + +#ifdef CONFIG_OPTEE + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + }; +#endif }; &soc { diff --git a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi index 494229e4e62a..f2c7bd919970 100644 --- a/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi @@ -6,13 +6,6 @@ #include "imx8mm-u-boot.dtsi" / { - firmware { - optee { - compatible = "linaro,optee-tz"; - method = "smc"; - }; - }; - wdt-reboot { compatible = "wdt-reboot"; bootph-pre-ram; -- 2.25.1
Re: [PATCH] spl: spl_nor: use panic instead of hang if booting fails
On Mon, Jan 30, 2023 at 11:03:03AM +0100, Mario Kicherer wrote: > On systems without a watchdog, using hang() prevents a system to > recover from an error. For example, a board could implement a boot > counter to switch to an alternative load address after some failed > tries. > > Signed-off-by: Mario Kicherer > --- > common/spl/spl.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index 2855cdd117..d1aa2fb8a9 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -822,11 +822,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > if (ret) { > if (CONFIG_IS_ENABLED(SHOW_ERRORS) && > CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT)) > - printf(SPL_TPL_PROMPT "failed to boot from all boot > devices (err=%d)\n", > -ret); > + panic(SPL_TPL_PROMPT "failed to boot from all boot > devices (err=%d)\n", > + ret); > else > - puts(SPL_TPL_PROMPT "failed to boot from all boot > devices\n"); > - hang(); > + panic_str(SPL_TPL_PROMPT "failed to boot from all boot > devices\n"); > } > > spl_perform_fixups(&spl_image); Not all platforms that use SPI in SPL have panic() (and related functions) available, so this introduces a number of fail to builds. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Add Renesas patch attribution domain mapping
On Tue, Jun 20, 2023 at 01:49:43PM +0200, Marek Vasut wrote: > Add domain mapping for the +renesas mail, so that the patches get > attributed to to Renesas Electronics correctly. > > Signed-off-by: Marek Vasut Applied to gitdm/u-boot, thanks! -- Tom signature.asc Description: PGP signature
Rockchip DWC2 issue
Hi, Has anyone tried to use dwc2 and echi port together with USB disk? look like this is not working with this combination on any Rockchip SoC's Here are the issues that I've reproduced in RK3328 where the disk connected in EHCI port is detecting but DWC2 is not. Any clue? => usb start starting USB... Bus usb@ff5c: USB EHCI 1.00 Bus usb@ff5d: USB OHCI 1.0 Bus usb@ff60: generic_phy_get_bulk : no phys property Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@ff58: USB DWC2 scanning bus usb@ff5c for devices... 2 USB Device(s) found scanning bus usb@ff5d for devices... 1 USB Device(s) found scanning bus usb@ff60 for devices... 1 USB Device(s) found scanning bus usb@ff58 for devices... Adding disk for usb_mass_storage.lun0 failed (err=-9223372036854775788/0x8014) device 'usb_mass_storage.lun0' failed to unbind 1 USB Device(s) found device 'usb_mass_storage.lun0' failed to unbind scanning usb for storage devices... 2 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 100mA) Generic Teclast CoolFlash 4163831324317134 1 Hub (12 Mb/s, 0mA) U-Boot Root Hub 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller 1 Hub (480 Mb/s, 0mA) U-Boot Root Hub Thanks, Jagan.
Re: [PATCH 1/3] binman: Allow to define custom arguments
Hi Jan, On Tue, 20 Jun 2023 at 11:37, Jan Kiszka wrote: > > On 20.06.23 12:11, Simon Glass wrote: > > Hi Jan, > > > > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: > >> > >> On 19.06.23 16:09, Simon Glass wrote: > >>> Hi Jan, > >>> > >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: > > On 19.06.23 14:36, Simon Glass wrote: > > Hi Jan, > > > > On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: > >> > >> On 15.06.23 13:46, Jan Kiszka wrote: > >>> On 15.06.23 13:38, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:21, Jan Kiszka > wrote: > > > > On 15.06.23 13:19, Simon Glass wrote: > >> Hi Jan, > >> > >> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka > >> wrote: > >>> > >>> On 15.06.23 12:55, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 11:26, Jan Kiszka > wrote: > > > > On 12.06.23 23:17, Simon Glass wrote: > >> Hi Jan, > >> > >> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka > >> wrote: > >>> > >>> From: Jan Kiszka > >>> > >>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., > >>> to inject > >>> specific settings. Will be used by IOT2050 first to define > >>> multiple > >>> of-lists. > >>> > >>> Signed-off-by: Jan Kiszka > >>> --- > >>> CC: Simon Glass > >>> --- > >>> Makefile | 1 + > >>> 1 file changed, 1 insertion(+) > >> > >> I'm really not keen on this, since it means that the Makefile > >> (or some > >> vars it sets) are again involved in controlling the image > >> generation. > >> It should really all be in the binman image description / > >> .dtsi file > > > > binman does not allow me to unrole of-list inside the dts file, > > does it? > > With such a feature, I wouldn't need any custom -a of-list-X > > switches > > and, thus, no such EXTRA_ARGS. > > Can you explain a bit more about what you mean by 'unrole'? It > is just > software, so anything should be possible. > >>> > >>> To use a DT sequence, I need to specify fit,ftd-list. But I can > >>> say > >>> > >>> fit,ftd-list = "first.dtb second.dtb" > >>> > >>> I rather need to go via the EntryArg indirection of the binman > >>> command line. > >> > >> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are > >> you > >> wanting to filter that list based on something else? > >> > >> I'm afraid I am really not following this at all. > > > > CONFIG_OF_LIST is not working here as we have two different boards > > with > > two different lists. > > But we only build one board at a time, don't we? > >>> > >>> No, this is about building two flash images for two different board > >>> generations in the same binman run (see patch 3). > >>> > > We could provide a way to select between different lists, but how > does > Makefile get access to them? > >>> > >>> See patch 3: known lists, now put into board config.mk. > >>> > >> > >> Any better suggestions for this issue? Otherwise, I will have to keep > >> binman args extension for now. > > > > I've dug into this a bit. The use of #defines and macros looks to be > > unnecessary, unless I am missing something. > > > > You can do things like this: > > > > fit_node: fit { > > // base definition of FIT > > }; > > > > the later on: > > > > fit_node: { > > #ifdef xxx > >// override a few things > >fit,fdt-list = ... > > #else > > > > #endif > > As I wrote already, I have a solution for that by using a template dtsi. > > > > > There is no need to specify the properties all at once. You can update > > a property later on just by referring to its node as above. > > Does not help when the anchor name needs to vary as well. That's where I > will use a #define to customize the template on include. > > > > > I think with this you should be above to eliminate BINMAN_EXTRA_ARGS > > and all the #define stuff. > > You still didn't address my question. Should I share my version to make > the problem clearer? But I thought I explained this in various shades > already. > >>> > >>> Yes, if I am looking at the wrong patches, please point me
Re: [PATCH v2] board_f: Relocate fdt even if GD_FLG_SKIP_RELOC is set
On Tue, 20 Jun 2023 at 11:50, Kunihiko Hayashi wrote: > > In case of OF_SEPARATE (!OF_EMBED), the devicetree blob is placed > after _end, and fdt_find_separate() always returns _end. There is > a .bss section after _end and the section is cleared before relocation. > > When GD_FLG_SKIP_RELOC is set, relocation is skipped, so the blob is > still in .bss section, but will be cleared. As a result, the devicetree > become invalid. > > To avoid this issue, should relocate it regardless of GD_FLG_SKIP_RELOC > in reloc_fdt(). > > Signed-off-by: Kunihiko Hayashi > --- > common/board_f.c | 2 -- > 1 file changed, 2 deletions(-) > > Changes since v1: > - Remove condition for skipping fdt relocation (always relocate) > Reviewed-by: Simon Glass
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
On Tue, 20 Jun 2023 at 12:20, Xavier Drudis Ferran wrote: > > El Tue, Jun 20, 2023 at 11:03:57AM +0100, Simon Glass deia: > > Hi Xavier, > > > > Hi Simon, > > > > > > > It is also possible that one day a device that is not UCLASS_BLK, > > > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage > > > device (just imagine a future system similar to bootstd for firmware > > > updates, trust material, etc.). Is it likely to have a struct in > > > parent_priv_ that is not a usb_device ? > > > > > > So which is more likely to survive future changes ? > > > > > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL > > > > > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not > > > UCLASS_BLK > > > (my patch, overcautious ?) > > > > > > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL) > > > (Simon Glass' idea) > > > > > > - checking for not UCLASS_BLK and not UCLASS_BOOTDEV and not > > > UCLASS_USB_EMUL > > >and parent_priv_ not null > > > > Really the parent_priv thing is a separate issue, a side effect of > > something having a UCLASS_USB parent. > > > > I don't think it's a separate issue. If parent_priv is present it > could be a usb_device (most likely) or not, but if it's null there's > no way the recursive call can succeed. > > > The key point here is that we cannot iterate down into a bootdev > > device looking for USB devices. So we should use that as the check, > > since it is the most direct check. > > > > But things keep appearing that have a UCLASS_USB* parent and no > parent_priv. > in 2017 Suneel Garapati already fixed the issue of UCLASS_BLK > being a child of a device. Now it's UCLASS_BOOTDEV, and tomorrow > may be something else. > > The most direct check will miss future cases as the devices tend to > become more abstract instead of mapping one to one to physical stuff. > > > > > >From my memory, I think you can check for a USB hub instead, but I'm > > not completely sure. > > > > On second thoughts I didn't find it so easy. There's the root hub, > UCLASS_USB, I think and a UCLASS_USB_EMUL may also be a hub, so I > don't know anymore how more elegant that could be, so I left it be. > > > I suggest adding a test for the command (see test/dm/acpi.c for an > > example) since a test is the best way to ensure this doesn't happen > > again. > > > > Makes sense. But I don't have any more time for that, sorry. > > I think we'll have to leave it at this unless someone else has the time. Reviewed-by: Simon Glass
Re: [PATCH v13 05/10] arm_ffa: introduce armffa command
[...] > > diff --git a/MAINTAINERS b/MAINTAINERS > index 43603522fd..0d960731cf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -269,7 +269,9 @@ F: configs/cortina_presidio-asic-pnand_defconfig > ARM FF-A > M: Abdellatif El Khlifi > S: Maintained > +F: cmd/armffa.c > F: doc/arch/arm64.ffa.rst > +F: doc/usage/cmd/armffa.rst > F: drivers/firmware/arm-ffa/ > F: include/arm_ffa.h > F: include/sandbox_arm_ffa.h > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 365371fb51..86af7bcc9e 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -934,6 +934,16 @@ endmenu > > menu "Device access commands" > > +config CMD_ARMFFA > + bool "Arm FF-A test command" > + depends on ARM_FFA_TRANSPORT > + help > + Provides a test command for the FF-A support > + supported options: > + - Listing the partition(s) info > + - Sending a data pattern to the specified partition > + - Displaying the arm_ffa device info > + > config CMD_ARMFLASH > #depends on FLASH_CFI_DRIVER > bool "armflash" > diff --git a/cmd/Makefile b/cmd/Makefile > index 6c37521b4e..7d20a85a46 100644 > --- a/cmd/Makefile > +++ b/cmd/Makefile > @@ -12,6 +12,7 @@ obj-y += panic.o > obj-y += version.o > > # command > +obj-$(CONFIG_CMD_ARMFFA) += armffa.o > obj-$(CONFIG_CMD_2048) += 2048.o > obj-$(CONFIG_CMD_ACPI) += acpi.o > obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o > diff --git a/cmd/armffa.c b/cmd/armffa.c > new file mode 100644 > index 00..fa268e9cb9 > --- /dev/null > +++ b/cmd/armffa.c > @@ -0,0 +1,196 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > + * > + * Authors: > + * Abdellatif El Khlifi > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/** > + * ffa_get_dev() - Return the FF-A device > + * @devp: pointer to the FF-A device > + * > + * Search for the FF-A device. > + * > + * Return: > + * 0 on success. Otherwise, failure > + */ > +int ffa_get_dev(struct udevice **devp) Why isn't this static? If it's used in another file we need to move it to a library suitable file. > +{ > + int ret; > + > + ret = uclass_first_device_err(UCLASS_FFA, devp); > + if (ret) { > + log_err("Cannot find FF-A bus device\n"); > + return ret; > + } > + > + return 0; > +} > + > +/** > + * do_ffa_getpart() - implementation of the getpart subcommand > + * @cmdtp: Command Table > + * @flag: flags > + * @argc: number of arguments > + * @argv: arguments > + * > + * Query the secure partition information which the UUID is provided > + * as an argument. The function uses the arm_ffa driver > + * partition_info_get operation which implements FFA_PARTITION_INFO_GET > + * ABI to retrieve the data. The input UUID string is expected to be in big > + * endian format. > + * > + * Return: > + * > + * CMD_RET_SUCCESS: on success, otherwise failure > + */ > +static int do_ffa_getpart(struct cmd_tbl *cmdtp, int flag, int argc, > + char *const argv[]) > +{ > + u32 count = 0; > + int ret; > + struct ffa_partition_desc *descs; > + u32 i; > + struct udevice *dev; > + > + if (argc != 2) { > + log_err("Missing argument\n"); > + return CMD_RET_USAGE; > + } > + > + ret = ffa_get_dev(&dev); > + if (ret) > + return CMD_RET_FAILURE; > + > + /* Ask the driver to fill the buffer with the SPs info */ > + > + ret = ffa_partition_info_get(dev, argv[1], &count, &descs); > + if (ret) { > + log_err("Failure in querying partition(s) info (error code: > %d)\n", ret); > + return CMD_RET_FAILURE; > + } > + > + /* SPs found , show the partition information */ > + for (i = 0; i < count ; i++) { > + log_info("Partition: id = %x , exec_ctxt %x , properties > %x\n", > +descs[i].info.id, > +descs[i].info.exec_ctxt, > +descs[i].info.properties); > + } > + > + return CMD_RET_SUCCESS; > +} > + > +/** > + * do_ffa_ping() - implementation of the ping subcommand > + * @cmdtp: Command Table > + * @flag: flags > + * @argc: number of arguments > + * @argv: arguments > + * > + * Send data to the secure partition which the ID is provided s/which/ in which/ > + * as an argument. Use the arm_ffa driver sync_send_receive operation > + * which implements FFA_MSG_SEND_DIRECT_{REQ,RESP} ABIs to send/receive data. > + * > + * Return: > + * > + * CMD_RET_SUCCESS: on success, otherwise failure > + */ > +int do_ffa_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const > argv[]) > +{ > + struct ffa_send_direct_data msg = { > +
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 16:13, Marek Vasut wrote: On 6/20/23 15:36, Michal Simek wrote: On 6/20/23 11:54, Marek Vasut wrote: On 6/20/23 11:42, Michal Simek wrote: On 6/20/23 11:23, Marek Vasut wrote: On 6/20/23 08:36, Michal Simek wrote: On 6/19/23 19:04, Eugen Hristev wrote: On 6/19/23 19:07, Marek Vasut wrote: On 6/19/23 15:26, Eugen Hristev wrote: On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: [ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/core.c | 50 +++-- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..8702a54efa 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - mdelay(100); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* Hello Venkatesh, Michal, I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I noticed that you removed the code that resets the PHYs in this patch hence DWC3 is no longer starting in my case. Was this intentional with this patch ? All of these patches are NAK until the DWC3 is synchronized with Linux. Picking random DWC3 patches and ignoring other fixes will turn the whole driver into an unmaintainable mess and make the sync that much harder in the future. I spent enormous amount of my spare time trying to explain to Xilinx how to do that mostly automatically, but that was all ignored or countered with reason after reason why this cannot be done, but as far as I can tell, nobody in Xilinx actually tried the proposal. Hence, NAK Hence, no need to worry these patches will be applied in their current state. Hi Marek, that's fine. No argument from my side. What I wanted to actually tell/ask , is the fact that this patch actually helps in my case, just that it breaks something else, and I wanted to get more info from the patch authors. I am experiencing some situations where dwc3 does not correctly start unless I add some manual delays here and there, and I am trying to see why. It is not just about dwc3. There are other parts which are ported from Linux kernel and are out of sync from Linux kernel for quite a long time. Another example is xhci - kernel 3.4. I am little bit worried that the whole usb stack is out of sync.
Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox
On 6/20/23 16:14, Jassi Brar wrote: On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas wrote: Sorry for being late to the party, +cc Jose who maintains DEN0118 On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote: Hi Michal, On Mon, 19 Jun 2023 at 10:02, Michal Simek wrote: Hi Jassi, On 5/31/23 07:28, jaswinder.si...@linaro.org wrote: From: Jassi Brar Introduce support for mtd backed storage for FWU feature and enable it on Synquacer platform based DeveloperBox. This revision is rebased onto patchset that trims the FWU api https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/ . Firstly I can generate 2 images per one bank which should be pretty much regular capsule update for 2 images. I would expect this should still work. And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() generated this description for DFU mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd nor0=bank0 raw 23a 400;bank1 raw 282 400 If you look at size in second entry you will see that it is 8000 instead of 8 because it is the same image. That's why curious if you have tested any scenario like this. I had, and have, strong doubts about the practicality of 2 images/bank. There aren't enough specification details to explain how only 1-out-of-N images could be updated. And if we always update all images in a bank together, we might as well have them as one composite image. I never got satisfactory clarification from designers and implementers. So, sorry, I can't defend that scenario with my limited knowledge. This is intentionally left out, as we consider it a platform policy. For example you could update a single bank and copy over the remaining firmware images from a different ban. There's nothing on the spec that prohibits you from doing so, but I personally think it's a bad idea. Me too. Keep in mind there's a document hosted here[0] which explains the update flow and documents what we have as code in U-Boot. As far as individual firmware components go now, do you have any useful usecase? No. And I don't think current A/B update implementation in u-boot even has helpers for platforms to implement multiple images per bank. Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK config -- which will always be set to 1 I predict ;) Actually support is there but it requires one thing to patch. I will send that patch when I clean my repo. And I have tested it on our platform. The general guidance of [0] is construct a firmware image, only update the components you want while leaving the rest on the same revisions and update the entire firmware. The reason is that firmware Updating a single image of another bank is not as easy as it sounds. exactly. Firmware components nowadays, whether we like it or not, depend on each other. Since firmware updates are not so often and fast, we didn't see any gains from over complicating the spec and explicitly describe that case, while dealing with firmware component compatibility at the same time. Totally. As I said, I don't believe in the practicality of more than 1 image/bank. So we are on the same page. Next part which I want to take a look is practicality of CONFIG_FWU_NUM_BANKS and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing number of banks and images for every platform and prevent creating one u-boot which works on different boards and just use information from mdata. DEN0118 doesn't show any field with this information but do you think that would be possible to extract that information from there based on for example reserved or accepted field? Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we use any bit, we'll be in violation of the spec. Yes this is unfortunate. We did have similar concerns on when drafting the spec, however we never had a solid usecase to justify this. Arm and Linaro and working on a v2 (which we try to make compatible with v1) which addresses this shortcoming. Maybe Jose can chime in. Another way would be to simply decode this information directly from DT fwu-mdata node. Because from that node it is clear how many banks and how many images that particular bank has. Thanks, Michal
Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox
On Tue, 20 Jun 2023 at 05:05, Ilias Apalodimas wrote: > > Sorry for being late to the party, > > +cc Jose who maintains DEN0118 > > On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote: > > Hi Michal, > > > > On Mon, 19 Jun 2023 at 10:02, Michal Simek wrote: > > > > > > Hi Jassi, > > > > > > On 5/31/23 07:28, jaswinder.si...@linaro.org wrote: > > > > From: Jassi Brar > > > > > > > > Introduce support for mtd backed storage for FWU feature and enable it > > > > on > > > > Synquacer platform based DeveloperBox. > > > > > > > > This revision is rebased onto patchset that trims the FWU api > > > > > > > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/ > > > > > > . > > > > > Firstly I can generate 2 images per one bank which should be pretty much > > > regular > > > capsule update for 2 images. I would expect this should still work. > > > > > > And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() > > > generated > > > this description for DFU > > > > > > mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd nor0=bank0 raw > > > 23a 400;bank1 raw 282 400 > > > > > > If you look at size in second entry you will see that it is 8000 instead > > > of > > > 8 because it is the same image. That's why curious if you have tested > > > any > > > scenario like this. > > > > > I had, and have, strong doubts about the practicality of 2 > > images/bank. There aren't enough specification details to explain how > > only 1-out-of-N images could be updated. And if we always update all > > images in a bank together, we might as well have them as one composite > > image. I never got satisfactory clarification from designers and > > implementers. So, sorry, I can't defend that scenario with my limited > > knowledge. > > This is intentionally left out, as we consider it a platform policy. > For example you could update a single bank and copy over the remaining > firmware images from a different ban. There's nothing on the spec that > prohibits you from doing so, but I personally think it's a bad idea. > Me too. > Keep in mind there's a document hosted here[0] which explains the update > flow and documents what we have as code in U-Boot. > > As far as individual firmware components go now, do you have any useful > usecase? > No. And I don't think current A/B update implementation in u-boot even has helpers for platforms to implement multiple images per bank. Which is fine, except we pretend we do by having NUM_IMAGES_PER_BANK config -- which will always be set to 1 I predict ;) > The general guidance of [0] is construct a firmware > image, only update the components you want while leaving the rest on the > same revisions and update the entire firmware. The reason is that firmware > > Updating a single image of another bank is not as easy as it sounds. > exactly. > Firmware components nowadays, whether we like it or not, depend on each other. > Since firmware updates are not so often and fast, we didn't see any gains > from > over complicating the spec and explicitly describe that case, while dealing > with firmware component compatibility at the same time. > Totally. As I said, I don't believe in the practicality of more than 1 image/bank. So we are on the same page. > > > > > Next part which I want to take a look is practicality of > > > CONFIG_FWU_NUM_BANKS > > > and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing > > > number of > > > banks and images for every platform and prevent creating one u-boot which > > > works > > > on different boards and just use information from mdata. > > > DEN0118 doesn't show any field with this information but do you think > > > that would > > > be possible to extract that information from there based on for example > > > reserved > > > or accepted field? > > > > > Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in > > 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we > > use any bit, we'll be in violation of the spec. > > Yes this is unfortunate. We did have similar concerns on when drafting the > spec, however we never had a solid usecase to justify this. Arm and > Linaro and working on a v2 (which we try to make compatible with v1) which > addresses this shortcoming. Maybe Jose can chime in. > OK. If we have, say, reserved[0] as last Image and reserved[1] as last Bank, we could get rid of the two compile-time configs. Thanks.
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 15:36, Michal Simek wrote: On 6/20/23 11:54, Marek Vasut wrote: On 6/20/23 11:42, Michal Simek wrote: On 6/20/23 11:23, Marek Vasut wrote: On 6/20/23 08:36, Michal Simek wrote: On 6/19/23 19:04, Eugen Hristev wrote: On 6/19/23 19:07, Marek Vasut wrote: On 6/19/23 15:26, Eugen Hristev wrote: On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: [ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/core.c | 50 +++-- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..8702a54efa 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - mdelay(100); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* Hello Venkatesh, Michal, I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I noticed that you removed the code that resets the PHYs in this patch hence DWC3 is no longer starting in my case. Was this intentional with this patch ? All of these patches are NAK until the DWC3 is synchronized with Linux. Picking random DWC3 patches and ignoring other fixes will turn the whole driver into an unmaintainable mess and make the sync that much harder in the future. I spent enormous amount of my spare time trying to explain to Xilinx how to do that mostly automatically, but that was all ignored or countered with reason after reason why this cannot be done, but as far as I can tell, nobody in Xilinx actually tried the proposal. Hence, NAK Hence, no need to worry these patches will be applied in their current state. Hi Marek, that's fine. No argument from my side. What I wanted to actually tell/ask , is the fact that this patch actually helps in my case, just that it breaks something else, and I wanted to get more info from the patch authors. I am experiencing some situations where dwc3 does not correctly start unless I add some manual delays here and there, and I am trying to see why. It is not just about dwc3. There are other parts which are ported from Linux kernel and are out of sync from Linux kernel for quite a long time. Another example is xhci - kernel 3.4. I am little bit worried that the whole usb stack is out of sync. AMD/Xilinx had the opp
Re: [PATCH v13 01/10] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers
Hi Abdellatif, On Fri, 16 Jun 2023 at 18:28, Abdellatif El Khlifi wrote: > > add support for x0-x17 registers used by the SMC calls > > In SMCCC v1.2 [1] arguments are passed in registers x1-x17. > Results are returned in x0-x17. > > This work is inspired from the following kernel commit: > > arm64: smccc: Add support for SMCCCv1.2 extended input/output registers > > [1]: > https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token= I did review this one in the past, any reason why that is missing? Did the file change? Thanks /Ilias > > Signed-off-by: Abdellatif El Khlifi > Reviewed-by: Jens Wiklander > Reviewed-by: Simon Glass > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > > --- > > Changelog: > === > > v9: > > * update the copyright string > > v7: > > * improve indentation of ARM_SMCCC_1_2_REGS_Xn_OFFS > > v4: > > * rename the commit title and improve description > new commit title: the current > > v3: > > * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2 > commit title: > arm64: smccc: add Xn registers support used by SMC calls > > arch/arm/cpu/armv8/smccc-call.S | 57 - > arch/arm/lib/asm-offsets.c | 16 + > include/linux/arm-smccc.h | 45 ++ > 3 files changed, 117 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S > index dc92b28777..93f66d3366 100644 > --- a/arch/arm/cpu/armv8/smccc-call.S > +++ b/arch/arm/cpu/armv8/smccc-call.S > @@ -1,7 +1,11 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (c) 2015, Linaro Limited > - */ > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > + * > + * Authors: > + * Abdellatif El Khlifi > +*/ > #include > #include > #include > @@ -45,3 +49,54 @@ ENDPROC(__arm_smccc_smc) > ENTRY(__arm_smccc_hvc) > SMCCC hvc > ENDPROC(__arm_smccc_hvc) > + > +#ifdef CONFIG_ARM64 > + > + .macro SMCCC_1_2 instr > + /* Save `res` and free a GPR that won't be clobbered */ > + stp x1, x19, [sp, #-16]! > + > + /* Ensure `args` won't be clobbered while loading regs in next step */ > + mov x19, x0 > + > + /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */ > + ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] > + ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] > + ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] > + ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] > + ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] > + ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] > + ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] > + ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] > + ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] > + > + \instr #0 > + > + /* Load the `res` from the stack */ > + ldr x19, [sp] > + > + /* Store the registers x0 - x17 into the result structure */ > + stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] > + stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] > + stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] > + stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] > + stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] > + stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] > + stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] > + stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] > + stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] > + > + /* Restore original x19 */ > + ldp xzr, x19, [sp], #16 > + ret > + .endm > + > +/* > + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, > + * struct arm_smccc_1_2_regs *res); > + */ > +ENTRY(arm_smccc_1_2_smc) > + SMCCC_1_2 smc > +ENDPROC(arm_smccc_1_2_smc) > + > +#endif > diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c > index 6de0ce9152..181a8ac4c2 100644 > --- a/arch/arm/lib/asm-offsets.c > +++ b/arch/arm/lib/asm-offsets.c > @@ -9,6 +9,11 @@ > * generate asm statements containing #defines, > * compile this file to assembler, and then extract the > * #defines from the assembly-language output. > + * > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > + * > + * Authors: > + * Abdellatif El Khlifi > */ > > #include > @@ -90,6 +95,17 @@ int main(void) > DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2)); > DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id)); > DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, > state)); > +#ifdef CONFIG_ARM64 > + DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS, offsetof(struct > arm_smccc_1_2_regs, a0)); > + DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS, offsetof(struct > arm_smccc_1_2_regs, a2)); > + DE
[PATCH v2 1/1] usb: dwc2: Fix the write to W1C fields in HPRT register
From: Teik Heng Chong Fix the write to the HPRT register which treat W1C fields as if they were mere RW. This leads to unintended clearing of such fields Signed-off-by: Teik Heng Chong --- V1->V2 - update subject tags to usb:dwc2 --- drivers/usb/host/dwc2.c | 34 -- drivers/usb/host/dwc2.h | 4 2 files changed, 12 insertions(+), 26 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..9818f9be94 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -315,9 +315,7 @@ static void dwc_otg_core_host_init(struct udevice *dev, /* Turn on the vbus power. */ if (readl(®s->gintsts) & DWC2_GINTSTS_CURMODE_HOST) { - hprt0 = readl(®s->hprt0); - hprt0 &= ~(DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET); - hprt0 &= ~(DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG); + hprt0 = readl(®s->hprt0) & ~DWC2_HPRT0_W1C_MASK; if (!(hprt0 & DWC2_HPRT0_PRTPWR)) { hprt0 |= DWC2_HPRT0_PRTPWR; writel(hprt0, ®s->hprt0); @@ -748,7 +746,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, case (USB_REQ_CLEAR_FEATURE << 8) | USB_RECIP_OTHER | USB_TYPE_CLASS: switch (wValue) { case USB_PORT_FEAT_C_CONNECTION: - setbits_le32(®s->hprt0, DWC2_HPRT0_PRTCONNDET); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTCONNDET); break; } break; @@ -759,21 +757,13 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, break; case USB_PORT_FEAT_RESET: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_POWER: - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | - DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); break; case USB_PORT_FEAT_ENABLE: @@ -1213,14 +1203,9 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) dwc_otg_core_host_init(dev, regs); } - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); mdelay(50); - clrbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | DWC2_HPRT0_PRTCONNDET | -DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG | -DWC2_HPRT0_PRTRST); + clrbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK | DWC2_HPRT0_PRTRST); for (i = 0; i < MAX_DEVICE; i++) { for (j = 0; j < MAX_ENDPOINT; j++) { @@ -1246,10 +1231,7 @@ static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv) static void dwc2_uninit_common(struct dwc2_core_regs *regs) { /* Put everything in reset. */ - clrsetbits_le32(®s->hprt0, DWC2_HPRT0_PRTENA | - DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG | - DWC2_HPRT0_PRTOVRCURRCHNG, - DWC2_HPRT0_PRTRST); + clrsetbits_le32(®s->hprt0, DWC2_HPRT0_W1C_MASK, DWC2_HPRT0_PRTRST); } #if !CONFIG_IS_ENABLED(DM_USB) diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index a6f562fe60..6f022e33a1 100644 --- a/drivers/usb/host/dwc2.h +++ b/drivers/usb/host/dwc2.h @@ -543,6 +543,10 @@ struct dwc2_core_regs { #define DWC2_HPRT0_PRTSPD_LOW (2 << 17) #define DWC2_HPRT0_PRTSPD_MASK (0x3 << 17) #define DWC2_HPRT0_PRTSPD_OFFSET 17 +#define DWC2_HPRT0_W1C_MASK(DWC2_HPRT0_PRTCONNDET | \ + DWC2_HPRT0_PRTENA | \ + DWC2_HPRT0_PRTENCHNG | \ +
Re: [PATCH v4 0/4] SPL NVMe support
On Sat, 03 Jun 2023 19:32:52 +0530, Mayuresh Chitale wrote: > This patchset adds support to load images of the SPL's next booting > stage from a NVMe device. > > Changes in v4: > - Drop patch 4 > - Modify patch 2 to use generic fs.h APIs > > [...] With one change, which is that the "disk/part.c" in 4/4 were not required for any platform in tree and also broke testcases, and so was dropped, this has now been applied to u-boot/next. If you can explain a bit more what the problem you had was, we can look in to it. I suspect you need to test for not SPL_ENV_SUPPORT but ENV_SUPPORT itself. -- Tom
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 11:54, Marek Vasut wrote: On 6/20/23 11:42, Michal Simek wrote: On 6/20/23 11:23, Marek Vasut wrote: On 6/20/23 08:36, Michal Simek wrote: On 6/19/23 19:04, Eugen Hristev wrote: On 6/19/23 19:07, Marek Vasut wrote: On 6/19/23 15:26, Eugen Hristev wrote: On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: [ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/core.c | 50 +++-- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..8702a54efa 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - mdelay(100); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* Hello Venkatesh, Michal, I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I noticed that you removed the code that resets the PHYs in this patch hence DWC3 is no longer starting in my case. Was this intentional with this patch ? All of these patches are NAK until the DWC3 is synchronized with Linux. Picking random DWC3 patches and ignoring other fixes will turn the whole driver into an unmaintainable mess and make the sync that much harder in the future. I spent enormous amount of my spare time trying to explain to Xilinx how to do that mostly automatically, but that was all ignored or countered with reason after reason why this cannot be done, but as far as I can tell, nobody in Xilinx actually tried the proposal. Hence, NAK Hence, no need to worry these patches will be applied in their current state. Hi Marek, that's fine. No argument from my side. What I wanted to actually tell/ask , is the fact that this patch actually helps in my case, just that it breaks something else, and I wanted to get more info from the patch authors. I am experiencing some situations where dwc3 does not correctly start unless I add some manual delays here and there, and I am trying to see why. It is not just about dwc3. There are other parts which are ported from Linux kernel and are out of sync from Linux kernel for quite a long time. Another example is xhci - kernel 3.4. I am little bit worried that the whole usb stack is out of sync. AMD/Xilinx had the opportunity and means to fix that worry, mostly in an autom
Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support
On Sun, 18 Jun 2023 13:01:33 -0600 Sam Edwards wrote: Hi Sam, thanks for the reply, that's very helpful. > On 6/14/23 18:07, Andre Przywara wrote: > > So I finally found some time to address some issues in the series, > > especially in the first patches (pinctrl rework and preparation). > > I pushed a branch to https://github.com/apritzel/u-boot/commits/r528-rc > > I need to do more testing, most importantly regression testing on other > > SoCs, and will only be able to post something next week, I guess. > > > > If you could briefly list the things that are still missing, I could > > try to pick some low hanging fruits. > > Rebasing onto this branch ended up eliminating a good chunk of my local > hack commits. I've verified that everything is still working (but have > not yet retested NAND SPL). Great, thanks! > The remaining local changes I have are two additions to cpu_sunxi_ncat2.h: > +#define SUNXI_R_CPUCFG_BASE 0x07000400 /* for PSCI */ > +#define SUNXI_RTC_BASE 0x0709 /* for FEL */ Right, I will definitely take the PSCI bit, but not so sure about FEL yet. > The former can probably be brought into my PSCI series somehow (unless > we expect more chips with CPUX blocks which might move those soft entry > registers around, then it should be defined in cpu_sunxi_*.h). The > latter is to support a reimplementation of Allwinner's `efex` command > that I'm using for development (it pokes the magic number 0x5AA5A55A > into RTC's GP_DATA_REG[2] and then resets; SPL clears that magic number > and then does an early branch to BROM+0x0020 -- exactly what Allwinner's > fork does). So yeah, the request of a "Enter FEL" command came up multiple times, but so far no one could be bothered to implement this properly. The idea would be to have a generic command (more like "fel-reset" than efex), and allow each SoC (family) to implement this differently, as every SoC requires something a bit different here (32-bit vs. 64-bit, having an RTC vs not, etc). If you could post your solution somewhere, we could start this effort. There was some patch for the H3 already, and it's relatively straight-forward on the newer SoCs (H616, IIRC), so if at least two popular, but different SoCs would be supported, we could make sure to have the right abstractions in place. > I've also noticed exactly(!) one formatting difference in our clk_d1.c: > - .num_gates = ARRAY_SIZE(d1_gates), > + .num_gates = ARRAY_SIZE(d1_gates), > > Up to you if you prefer to align the = or not, but it does look > inconsistent when .gates and .resets are aligned and .num_* aren't - > might be a nitpick that comes up in patch review. Well, this is how it is in all the other clock drivers, so I chose to stay consistent with them ;-) > > Interesting, indeed this is left at 0, which I think will result in 288 > > MHz. > > Correct, at least that's what I was seeing. > > > What is that frequency in your case? Do you know what the BSP > > programs? > > 1008 MHz, both. > > > Traditionally we used something conservative that works > > without cooling and with the default voltage, but I don't know that > > value for the T113s. > > For what it's worth, this board has a bare T113-s3 and the current OS > does not reclock from 1008 MHz at all, and I don't know of any users of > the board having stability issues. > > In my own case, it idles at that clock at around ~35°C. OK, many thanks, it looks like 1008 MHz it is, then. > > I think CLK_SUN20I_D1 should be set by default now, so can you check > > that this is fixed? > > It is now gone from my defconfig and still working, so indeed this is fixed. > > > Why would we need H6 PSCI support? On the ARMv8 parts we use Trusted > > Firmware-A (TF-A) to provide PSCI services, which has a much more mature > > implementation. > > It's not about the H6 and more about me being unsure whether R528/T113 > is the first ARMv7-based SoC to use the new CPU management registers. If > it's not, and there's another such chip supported in U-Boot that just > lacks PSCI, it would make more sense for me to land my PSCI series > independently of our work here, and then you can add the R528 case > later. It sounds like R528/T113 may be the first such chip needing this > new code, though, so this may have to wait until the R528 series lands. > > > How would this conflict, exactly? I don't see any other I2C2 > > definition? > > Well, no, the other definitions haven't landed in U-Boot yet. But they > do exist in the kernel, datasheets, and physical chips themselves: > > PB0/PB1/PB8/PB9/PE4/PE5: i2c2 defined as muxval 4 > PC0/PC1/PD20/PD21/PG6/PG7/PG14/PG15: i2c2 defined as muxval 3 > PE12/PE13: i2c2 defined as muxval 2 > > Defining i2c2=2 universally would mean that the pins for i2c2 cannot be > changed, since it would conflict with every other definition. Well, we are well aware that the current pinmux code is limited, but we figured it does wor
[PATCH] Add Renesas patch attribution domain mapping
Add domain mapping for the +renesas mail, so that the patches get attributed to to Renesas Electronics correctly. Signed-off-by: Marek Vasut --- u-boot-config/domain-map | 3 +++ 1 file changed, 3 insertions(+) diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map index f64147e..478696f 100644 --- a/u-boot-config/domain-map +++ b/u-boot-config/domain-map @@ -536,3 +536,6 @@ s...@chromium.org Google, Inc. # Louis Yung-Chieh Lo # yj...@google.com Google, Inc. + +# Marek Vasut +marek.vasut+rene...@mailbox.orgRenesas Electronics -- 2.39.2
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
El Tue, Jun 20, 2023 at 11:03:57AM +0100, Simon Glass deia: > Hi Xavier, > Hi Simon, > > > > It is also possible that one day a device that is not UCLASS_BLK, > > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage > > device (just imagine a future system similar to bootstd for firmware > > updates, trust material, etc.). Is it likely to have a struct in > > parent_priv_ that is not a usb_device ? > > > > So which is more likely to survive future changes ? > > > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL > > > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not > > UCLASS_BLK > > (my patch, overcautious ?) > > > > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL) > > (Simon Glass' idea) > > > > - checking for not UCLASS_BLK and not UCLASS_BOOTDEV and not > > UCLASS_USB_EMUL > >and parent_priv_ not null > > Really the parent_priv thing is a separate issue, a side effect of > something having a UCLASS_USB parent. > I don't think it's a separate issue. If parent_priv is present it could be a usb_device (most likely) or not, but if it's null there's no way the recursive call can succeed. > The key point here is that we cannot iterate down into a bootdev > device looking for USB devices. So we should use that as the check, > since it is the most direct check. > But things keep appearing that have a UCLASS_USB* parent and no parent_priv. in 2017 Suneel Garapati already fixed the issue of UCLASS_BLK being a child of a device. Now it's UCLASS_BOOTDEV, and tomorrow may be something else. The most direct check will miss future cases as the devices tend to become more abstract instead of mapping one to one to physical stuff. > > >From my memory, I think you can check for a USB hub instead, but I'm > not completely sure. > On second thoughts I didn't find it so easy. There's the root hub, UCLASS_USB, I think and a UCLASS_USB_EMUL may also be a hub, so I don't know anymore how more elegant that could be, so I left it be. > I suggest adding a test for the command (see test/dm/acpi.c for an > example) since a test is the best way to ensure this doesn't happen > again. > Makes sense. But I don't have any more time for that, sorry. I think we'll have to leave it at this unless someone else has the time. Bye.
[PATCH v2] board_f: Relocate fdt even if GD_FLG_SKIP_RELOC is set
In case of OF_SEPARATE (!OF_EMBED), the devicetree blob is placed after _end, and fdt_find_separate() always returns _end. There is a .bss section after _end and the section is cleared before relocation. When GD_FLG_SKIP_RELOC is set, relocation is skipped, so the blob is still in .bss section, but will be cleared. As a result, the devicetree become invalid. To avoid this issue, should relocate it regardless of GD_FLG_SKIP_RELOC in reloc_fdt(). Signed-off-by: Kunihiko Hayashi --- common/board_f.c | 2 -- 1 file changed, 2 deletions(-) Changes since v1: - Remove condition for skipping fdt relocation (always relocate) diff --git a/common/board_f.c b/common/board_f.c index 1688e27071fc..334d04af197b 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -633,8 +633,6 @@ static int init_post(void) static int reloc_fdt(void) { if (!IS_ENABLED(CONFIG_OF_EMBED)) { - if (gd->flags & GD_FLG_SKIP_RELOC) - return 0; if (gd->new_fdt) { memcpy(gd->new_fdt, gd->fdt_blob, fdt_totalsize(gd->fdt_blob)); -- 2.25.1
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
El Tue, Jun 20, 2023 at 11:49:36AM +0200, Marek Vasut deia: > > Default, see: > $ git grep CONFIG_BOOTCOMMAND configs/ > I'm lost. I called default what Kconfig used as default. You seem to call default what's in board specific config files. Whatever. Fix the wording in the commit message if you like. > > So, what is the minimal test case ? > I have been asking for that for a while. > I sent a minimal test case last week. https://lists.denx.de/pipermail/u-boot/2023-June/520109.html You build for a Rock Pi 4 board, boot with usb stick and no boot media and run usb info and you get a reset. I won't send it again because I can't guess what you consider minimal. > > I would really like a minimal test case. Empty your env and figure out the > commands which need to be executed to trigger this. Without any interference > from other commands/scripting/... > I'm sorry but if what I sent isn't enough I don't think I'll have time to help you any further. Find your minimal test case yourself or ignore my patch. > > If it's just that you can't reproduce it, can you try to ?: > > > > - set up a board with no boot media (I tested like this but it might > >not be needed), > > > > - put usb in boot_targets (if you put only usb there you may not need > >the previous step): > >setenv boot_targets usb > > Here you assume distro bootcommand or some such . Can we remove that > assumption ? (I think yes, and we should) > I don't think I'm assuming anything about bootcommand. That's precisely why I wrote these steps instead of the "just boot a Rock Pi 4" scenario last week. The commit message talks about bootcmd because it justifies that the bootflow scan will be called automatically in some cases, so the bug has more impact that it would otherwise have. But the bug should appear whether or not you have bootcmd. The bug should be an interaction between what bootflow scan does and what usb info or usb tree do. I'm assuming bootflow reads the boot_targets environment variable to know where it searches for boot devices, and therefore to which devices it will attach a UCLASS_BOOTDEV child to some devices, in particular to usb mass storage devices if any is present, that will later break usb info/usb tree. Whether bootflow is called from bootcmd or not should be irrelevant. If you follow the code from the bootflow command you may find yourself that the boot_targets variable is involved. I did it last week or sometime and won't do it again now for you, sorry. I know I may have misunderstood something, and I'm sorry for the noise if so. > > - plug a non-booting usb mass storage device to an usb port, > > > > - run usb reset in case you already had usb initialized at boot, or > >skip this if usb is not initialized yet. If in doubt, run usb reset. > > > > - run bootflow scan > > > > - run usb info > > > > It should list some devices, but give you a reset just after listing the > > usb mass storage device without my patch, and it should just list all > > usb devices and go back to the prompt with my patch. > > Does it crash if you empty your env and run simply > > => usb reset ; bootflow scan ; usb info > > ? I guess it won't crash if environment var boot_targets is absent or empty. Or even if it's full but has no "usb" in it. But I'm not sure anymore at what time the variable is read, so it might be that emptying it when bootflow structures are already set up wouldn't change things, I don't know, I don't remember. But I won't try it, sorry. I found a bug, I sent a 4 line patch. Since I didn't justify it enough I sent followup mails on how to reproduce. This week I sent a second version, with redundant measures to seek consensus. It's a 6 line patch or 8 or whatever. I didn't write bootflow, and I didn't write cmd/usb.c And I don't have time to keep writing long emails. I'm sorry. Not even to count how many lines of text I wrote compared to the 8 lines of code or whatever. If someone has the bureaucratic skills and patience to pursue this further, they can do what they want with my patch (under GPL2 as implied by the sign off). If not, you all can keep your bugs, I won't try anymore to steal them. Bye and sorry for any disturbances.
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 20.06.23 12:11, Simon Glass wrote: > Hi Jan, > > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: >> >> On 19.06.23 16:09, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: On 19.06.23 14:36, Simon Glass wrote: > Hi Jan, > > On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >> >> On 15.06.23 13:46, Jan Kiszka wrote: >>> On 15.06.23 13:38, Simon Glass wrote: Hi Jan, On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: > > On 15.06.23 13:19, Simon Glass wrote: >> Hi Jan, >> >> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka >> wrote: >>> >>> On 15.06.23 12:55, Simon Glass wrote: Hi Jan, On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: > > On 12.06.23 23:17, Simon Glass wrote: >> Hi Jan, >> >> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >> wrote: >>> >>> From: Jan Kiszka >>> >>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to >>> inject >>> specific settings. Will be used by IOT2050 first to define >>> multiple >>> of-lists. >>> >>> Signed-off-by: Jan Kiszka >>> --- >>> CC: Simon Glass >>> --- >>> Makefile | 1 + >>> 1 file changed, 1 insertion(+) >> >> I'm really not keen on this, since it means that the Makefile >> (or some >> vars it sets) are again involved in controlling the image >> generation. >> It should really all be in the binman image description / .dtsi >> file > > binman does not allow me to unrole of-list inside the dts file, > does it? > With such a feature, I wouldn't need any custom -a of-list-X > switches > and, thus, no such EXTRA_ARGS. Can you explain a bit more about what you mean by 'unrole'? It is just software, so anything should be possible. >>> >>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>> >>> fit,ftd-list = "first.dtb second.dtb" >>> >>> I rather need to go via the EntryArg indirection of the binman >>> command line. >> >> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >> wanting to filter that list based on something else? >> >> I'm afraid I am really not following this at all. > > CONFIG_OF_LIST is not working here as we have two different boards > with > two different lists. But we only build one board at a time, don't we? >>> >>> No, this is about building two flash images for two different board >>> generations in the same binman run (see patch 3). >>> We could provide a way to select between different lists, but how does Makefile get access to them? >>> >>> See patch 3: known lists, now put into board config.mk. >>> >> >> Any better suggestions for this issue? Otherwise, I will have to keep >> binman args extension for now. > > I've dug into this a bit. The use of #defines and macros looks to be > unnecessary, unless I am missing something. > > You can do things like this: > > fit_node: fit { > // base definition of FIT > }; > > the later on: > > fit_node: { > #ifdef xxx >// override a few things >fit,fdt-list = ... > #else > > #endif As I wrote already, I have a solution for that by using a template dtsi. > > There is no need to specify the properties all at once. You can update > a property later on just by referring to its node as above. Does not help when the anchor name needs to vary as well. That's where I will use a #define to customize the template on include. > > I think with this you should be above to eliminate BINMAN_EXTRA_ARGS > and all the #define stuff. You still didn't address my question. Should I share my version to make the problem clearer? But I thought I explained this in various shades already. >>> >>> Yes, if I am looking at the wrong patches, please point me to the >>> correct series, or push a tree somewhere. >>> >> >> Please have a look at >> https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e > > OK that looks a lot better to me. We can go with that until we come up > with something better. > > There has been a long-standing request to support common parts of images. > > I am thinking something
Re: [PATCH] board_f: Relocate fdt if SKIP_RELOC and fdt is in bss
Hi Simon, On 2023/06/19 21:36, Simon Glass wrote: Hi Kunihiko, On Fri, 16 Jun 2023 at 00:59, Kunihiko Hayashi wrote: Hi Simon, Thank you for your comment. On 2023/06/13 6:17, Simon Glass wrote: Hi Kunihiko, On Thu, 8 Jun 2023 at 07:53, Kunihiko Hayashi wrote: There are cases that the devicetree blob is placed after _end, such as fdt_find_separate() returns _end. This is in bss area cleared before relocation. When GD_FLG_SKIP_RELOC is set, the blob is still in bss, but will be cleared. As a result, the devicetree become invalid. To avoid this issue, should relocate it to the new fdt area using the latter condition in reloc_fdt(). Signed-off-by: Kunihiko Hayashi --- common/board_f.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index 51d2f3c365e9..9a245872d190 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -622,7 +622,8 @@ static int init_post(void) static int reloc_fdt(void) { if (!IS_ENABLED(CONFIG_OF_EMBED)) { - if (gd->flags & GD_FLG_SKIP_RELOC) + if (gd->flags & GD_FLG_SKIP_RELOC && + gd->fdt_blob != &_end) !IS_ENABLED(CONFIG_OF_EMBED) == IS_ENABLED(CONFIG_OF_SEPARATE) reloc_fdt() is only called by U-Boot (not SP) So the FDT was found by fdt_find_separate() and gd->fdt_blob == &_end So, is there any case where: gd->flags & GD_FLG_SKIP_RELO is true gd->fdt_blob != &_end is true ? Yes. But in fact, if (gd->flags & GD_FLG_SKIP_RELOC is true) and (gd->fdt_blob overlaps .bss section), the fdt should be relocated because clear_bss() will clear the fdt after that. I misstated my point. I am wondering if gd(->fdt_blob != &_end) is ever false? If not, then we can always relocate. When CONFIG_OF_SEPARATE is true, it seems that (gd->fdt_blob != &_end) is always false because the fdt file is concatinated to the end of the image file in Makefile. I can't think of one. If that is the case, then you could add a comment to this effect and unconditionally relocate if !CONFIG_OF_EMBED. I'm not sure if it is possible to unconditionally relocate the fdt, I think we need to know if the fdt overlaps .bss section. What is the down-side of always relocating, and when would the fdt not overlap the .bss section? The fdt always overlaps the .bss section, so it should be relocated even if (gd->flags & GL_FLG_SKIP_RELOC) is true. Note that OF_EMBED is not to be used in production boards. That is violated by a few things at present, but IMO always relocating should be safe. Yes, I undestand. I delete the condition in v2, and change to always relocate the fdt in case of !OF_EMBED. Thank you, --- Best Regards Kunihiko Hayashi
Re: [PATCH v13 05/10] arm_ffa: introduce armffa command
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi wrote: > > Provide armffa command showcasing the use of the U-Boot FF-A support > > armffa is a command showcasing how to invoke FF-A operations. > This provides a guidance to the client developers on how to > call the FF-A bus interfaces. The command also allows to gather secure > partitions information and ping these partitions. The command is also > helpful in testing the communication with secure partitions. > > For more details please refer to the command documentation [1]. > > [1]: doc/usage/cmd/armffa.rst > > Signed-off-by: Abdellatif El Khlifi > Reviewed-by: Simon Glass > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > Cc: Heinrich Schuchardt > > --- > > Changelog: > === > > v12: > > * add subcommands argument checks > * usage documentation: update command return codes > * remove calloc when querying SPs > * address nits > > v11: > > * use U_BOOT_CMD_WITH_SUBCMDS > * address nits > > v10: > > * use the FF-A driver Uclass operations > * use uclass_first_device() > * address nits > > v9: > > * remove manual FF-A discovery and use DM > * use DM class APIs to probe and interact with the FF-A bus > * add doc/usage/cmd/armffa.rst > > v8: > > * update partition_info_get() second argument to be an SP count > * pass NULL device pointer to the FF-A bus discovery and operations > > v7: > > * adapt do_ffa_dev_list() following the recent update on > uclass_first_device/uclass_next_device functions (they return void now) > * set armffa command to use 64-bit direct messaging > > v4: > > * remove pattern data in do_ffa_msg_send_direct_req > > v3: > > * use the new driver interfaces (partition_info_get, sync_send_receive) > in armffa command > > v2: > > * replace use of ffa_helper_init_device function by > ffa_helper_bus_discover > > v1: > > * introduce armffa command > > MAINTAINERS | 2 + > cmd/Kconfig | 10 ++ > cmd/Makefile | 1 + > cmd/armffa.c | 196 +++ > doc/arch/arm64.ffa.rst | 7 ++ > doc/usage/cmd/armffa.rst | 93 +++ > doc/usage/index.rst | 1 + > drivers/firmware/arm-ffa/Kconfig | 1 + > 8 files changed, 311 insertions(+) > create mode 100644 cmd/armffa.c > create mode 100644 doc/usage/cmd/armffa.rst > Reviewed-by: Simon Glass
Re: [PATCH v13 09/10] arm_ffa: efi: introduce FF-A MM communication
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi wrote: > > Add MM communication support using FF-A transport > > This feature allows accessing MM partitions services through > EFI MM communication protocol. MM partitions such as StandAlonneMM > or smm-gateway secure partitions which reside in secure world. > > An MM shared buffer and a door bell event are used to exchange > the data. > > The data is used by EFI services such as GetVariable()/SetVariable() > and copied from the communication buffer to the MM shared buffer. > > The secure partition is notified about availability of data in the > MM shared buffer by an FF-A message (door bell). > > On such event, MM SP can read the data and updates the MM shared > buffer with the response data. > > The response data is copied back to the communication buffer and > consumed by the EFI subsystem. > > MM communication protocol supports FF-A 64-bit direct messaging. > > Signed-off-by: Abdellatif El Khlifi > Signed-off-by: Gowtham Suresh Kumar > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > > --- > > Changelog: > === > > v13: > > * remove FF-A and Optee ifdefs > > v12: > > * drop use of calloc when querying SPs > * address nits > > v11: > > * rename select_ffa_mm_comms() to select_mm_comms() > * improve the logic of MM transport selection in mm_communicate() > * addressing nits > > v10: > > * use the FF-A driver Uclass operations > * use uclass_first_device() > * addressing nits > > v9: align how FF-A is used with FF-A discovery through DM > > v8: > > * isolate the compilation choices between FF-A and OP-TEE > * update partition_info_get() second argument to be an SP count > * pass NULL device pointer to the FF-A bus discovery and operations > > v7: > > * set the MM door bell event to use 64-bit direct messaging > * issue a compile time error when one of these macros are not found : > FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET, > FFA_SHARED_MM_BUFFER_ADDR > * make mm_sp_svc_uuid static > * replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails > * improve use of unmap_sysmem() in ffa_mm_communicate() > > v6: > > * add FF-A runtime discovery at MM communication level > * drop EFI runtime support for FF-A MM communication > * revert the changes in include/mm_communication.h for > efi_mm_communicate_header and smm_variable_access structures > > v4: > > * use the new FF-A driver interfaces > * discover MM partitions at runtime > * copy FF-A driver private data to EFI runtime section at > ExitBootServices() > * drop use of FFA_ERR_STAT_SUCCESS error code > * replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES > in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore > * revert the error log in mm_communicate() in case of failure > * remove packed attribute from efi_mm_communicate_header and > smm_variable_communicate_header > > v2: > > * set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE, > FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings > > v1: > > * introduce FF-A MM communication > > include/mm_communication.h| 13 ++ > lib/efi_loader/Kconfig| 16 +- > lib/efi_loader/efi_variable_tee.c | 260 +- > 3 files changed, 282 insertions(+), 7 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v13 04/10] arm_ffa: introduce Arm FF-A support
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi wrote: > > Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0 > > The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1] > describes interfaces (ABIs) that standardize communication > between the Secure World and Normal World leveraging TrustZone > technology. > > This driver uses 64-bit registers as per SMCCCv1.2 spec and comes > on top of the SMCCC layer. The driver provides the FF-A ABIs needed for > querying the FF-A framework from the secure world. > > The driver uses SMC32 calling convention which means using the first > 32-bit data of the Xn registers. > > All supported ABIs come with their 32-bit version except FFA_RXTX_MAP > which has 64-bit version supported. > > Both 32-bit and 64-bit direct messaging are supported which allows both > 32-bit and 64-bit clients to use the FF-A bus. > > FF-A is a discoverable bus and similar to architecture features. > FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed > by the PSCI driver. > > Clients are able to probe then use the FF-A bus by calling the DM class > searching APIs (e.g: uclass_first_device). > > The Secure World is considered as one entity to communicate with > using the FF-A bus. FF-A communication is handled by one device and > one instance (the bus). This FF-A driver takes care of all the > interactions between Normal world and Secure World. > > The driver exports its operations to be used by upper layers. > > Exported operations: > > - ffa_partition_info_get > - ffa_sync_send_receive > - ffa_rxtx_unmap > > Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c). > Arm specific methods are implemented in the Arm driver (arm-ffa.c). > > For more details please refer to the driver documentation [2]. > > [1]: https://developer.arm.com/documentation/den0077/latest/ > [2]: doc/arch/arm64.ffa.rst > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > Cc: Heinrich Schuchardt > > --- > > Changelog: > === > > v13: > > * doc minor change: specify in the readme that the user >should call ffa_rxtx_unmap() driver operation to unmap >the RX/TX buffers on demand. > > v12: > > * remove dscvry_info > * replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn >(user drivers can override it) > * improve FFA_PARTITION_INFO_GET implementation >(clients no longer need to calloc a buffer) > * address nits > > v11: > > * move ffa_try_discovery() from the uclass to the Arm FF-A driver > * rename ffa_try_discovery() to arm_ffa_discover() > * pass dev as an argument of arm_ffa_discover() > * add arm_ prefix to the Arm FF-A driver functions > * add emul field in struct ffa_discovery_info > * address nits > > v10: > > * provide the driver operations through the Uclass > * move the generic FF-A methods to the Uclass > * keep Arm specific methods in the Arm driver (arm-ffa.c) > * rename core.c to arm-ffa.c > * address nits > > v9: > > * integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for > binding > > v8: > > * make ffa_get_partitions_info() second argument to be an SP count in both > modes > * update ffa_bus_prvdata_get() to return a pointer rather than a pointer > address > * remove packing from ffa_partition_info and ffa_send_direct_data structures > * pass the FF-A bus device to the bus operations > > v7: > > * add support for 32-bit direct messaging > * rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin() > * improve the declaration of error handling mapping > * stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported > > v6: > > * drop use of EFI runtime support (We decided with Linaro to add this later) > * drop discovery from initcalls (discovery will be on demand by FF-A users) > * set the alignment of the RX/TX buffers to the larger translation granule > size > * move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit > * update the documentation and move it to doc/arch/arm64.ffa.rst > > v4: > > * add doc/README.ffa.drv > * moving the FF-A driver work to drivers/firmware/arm-ffa > * use less #ifdefs in lib/efi_loader/efi_boottime.c and replace > #if defined by #if CONFIG_IS_ENABLED > * improving error handling by mapping the FF-A errors to standard errors > and logs > * replacing panics with an error log and returning an error code > * improving features discovery in FFA_FEATURES by introducing > rxtx_min_pages private data field > * add ffa_remove and ffa_unbind functions > * improve how the driver behaves when bus discovery is done more than > once > > v3: > > * align the interfaces of the U-Boot FF-A driver with those in the linux > FF-A driver > * remove the FF-A helper layer > * make the U-Boot FF-A driver independent from EFI > * provide an optional config that enables copying the driver data to EFI > runtime section at ExitBootServices service > * use 64-bit version
Re: [PATCH v13 03/10] lib: uuid: introduce testcase for uuid_str_to_le_bin
On Fri, 16 Jun 2023 at 16:28, Abdellatif El Khlifi wrote: > > provide a test case > > Signed-off-by: Abdellatif El Khlifi > Cc: Simon Glass > > --- > > Changelog: > === > > v11: > > * use ut_asserteq_mem() > > MAINTAINERS | 5 + > test/lib/Makefile | 1 + > test/lib/uuid.c | 41 + > 3 files changed, 47 insertions(+) > create mode 100644 test/lib/uuid.c > Reviewed-by: Simon Glass
Re: [PATCH] mkimage: Use PATH_MAX for path length
On Mon, 19 Jun 2023 at 17:25, wrote: > > From: Mingli Yu > > Fixed when build xilinx_zynqmp in long directory ( >256): > | > /buildarea1/testtest/wr_build/wr1023test_secureboot/test1-what/test2-what/test3-what/test4-what/test5-what/test6-what/test7-what/test8-what/test9-what/test10-what/test11-what/test12-what/build/tmp-glibc/work/xilinx_zynqmp-wrs-linux/u-boot-xlnx/1_v2023.01-xilinx-v2023.1+gitAUTOINC+40a08d69e7-r0/build/fitImage-linux: > Image file name (uboot-mkimage) too long, can't create tmpfile. > | Error: Bad parameters for FIT image type > > Signed-off-by: Mingli Yu > --- > tools/mkimage.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
Hi Tom, Pali, On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: > > On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: > > > These 3 commits broke support for U-Boot Bootmenu on Nokia N900. > > Issues were reported more than month ago, but nobody reacted to them. > > So revert these broken commits for now, to fix U-Boot Bootmenu support. > > > > With these revered commits, U-Boot Bootmenu from master branch is > > working fine again on Nokia N900. > > > > Pali Rohár (3): > > Revert "video: Enable VIDEO_ANSI by default only with EFI" > > Revert "menu: Factor out menu-keypress decoding" > > Revert "menu: Make use of CLI character processing" > > > > cmd/bootmenu.c| 9 ++-- > > cmd/eficonfig.c | 12 ++--- > > common/cli_getch.c| 12 ++--- > > common/menu.c | 122 ++ > > drivers/video/Kconfig | 7 +-- > > include/cli.h | 4 +- > > include/menu.h| 17 +- > > 7 files changed, 91 insertions(+), 92 deletions(-) > > Following up over here, while > https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ > addresses some of the issues, but not all (as it clearly isn't working > in all of the cases Pali has explained), looking in to the VIDEO_ANSI > part of this too, all three of these reverts are related seemingly to > something escape-character related. I'm not taking any of the revert > commits in just yet, but will by the next -rc if we don't have something > that fixes all of the issues. I did send a series [1] with a fix for the nokia_rx51 keyboard driver, including the previous ansi-code patch. Given that: - this problem doesn't seem to manifest on other boards - it does not cause any CI test to fail - there seem to be bugs in the nokia_rx51 implementation which are a possible/likely cause - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU - the problem goes away if debugging is added, suggesting it is related to timing ...I don't think a revert is appropriate. Pali, can you please take a look and see if you can debug what is actually going on? Here is my guess: 1. When an arrow key is pressed, cli_ch_process() handles it by being passed the codes in sequence: \e [ B 2. Calling cli_ch_process() with ichar = 0 causes it to think the sequence is finished: \e [ \0 B (this doesn't work since the \0 ends the sequence) 3. nokia_rx51 keyboard driver is returning '\0' even when key codes are pending, causing cli_ch_process() to be told that the sequence is done It would help to move the keyboard driver into drivers/input/ so it is easier to find. Regards, Simon [1] https://patchwork.ozlabs.org/project/uboot/list/?series=360134
Re: [PATCH 1/3] binman: Allow to define custom arguments
Hi Jan, On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: > > On 19.06.23 16:09, Simon Glass wrote: > > Hi Jan, > > > > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: > >> > >> On 19.06.23 14:36, Simon Glass wrote: > >>> Hi Jan, > >>> > >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: > > On 15.06.23 13:46, Jan Kiszka wrote: > > On 15.06.23 13:38, Simon Glass wrote: > >> Hi Jan, > >> > >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka > >> wrote: > >>> > >>> On 15.06.23 13:19, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:09, Jan Kiszka > wrote: > > > > On 15.06.23 12:55, Simon Glass wrote: > >> Hi Jan, > >> > >> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka > >> wrote: > >>> > >>> On 12.06.23 23:17, Simon Glass wrote: > Hi Jan, > > On Mon, 5 Jun 2023 at 15:39, Jan Kiszka > wrote: > > > > From: Jan Kiszka > > > > Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to > > inject > > specific settings. Will be used by IOT2050 first to define > > multiple > > of-lists. > > > > Signed-off-by: Jan Kiszka > > --- > > CC: Simon Glass > > --- > > Makefile | 1 + > > 1 file changed, 1 insertion(+) > > I'm really not keen on this, since it means that the Makefile > (or some > vars it sets) are again involved in controlling the image > generation. > It should really all be in the binman image description / .dtsi > file > >>> > >>> binman does not allow me to unrole of-list inside the dts file, > >>> does it? > >>> With such a feature, I wouldn't need any custom -a of-list-X > >>> switches > >>> and, thus, no such EXTRA_ARGS. > >> > >> Can you explain a bit more about what you mean by 'unrole'? It is > >> just > >> software, so anything should be possible. > > > > To use a DT sequence, I need to specify fit,ftd-list. But I can say > > > > fit,ftd-list = "first.dtb second.dtb" > > > > I rather need to go via the EntryArg indirection of the binman > > command line. > > Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you > wanting to filter that list based on something else? > > I'm afraid I am really not following this at all. > >>> > >>> CONFIG_OF_LIST is not working here as we have two different boards > >>> with > >>> two different lists. > >> > >> But we only build one board at a time, don't we? > > > > No, this is about building two flash images for two different board > > generations in the same binman run (see patch 3). > > > >> > >> We could provide a way to select between different lists, but how does > >> Makefile get access to them? > > > > See patch 3: known lists, now put into board config.mk. > > > > Any better suggestions for this issue? Otherwise, I will have to keep > binman args extension for now. > >>> > >>> I've dug into this a bit. The use of #defines and macros looks to be > >>> unnecessary, unless I am missing something. > >>> > >>> You can do things like this: > >>> > >>> fit_node: fit { > >>> // base definition of FIT > >>> }; > >>> > >>> the later on: > >>> > >>> fit_node: { > >>> #ifdef xxx > >>>// override a few things > >>>fit,fdt-list = ... > >>> #else > >>> > >>> #endif > >> > >> As I wrote already, I have a solution for that by using a template dtsi. > >> > >>> > >>> There is no need to specify the properties all at once. You can update > >>> a property later on just by referring to its node as above. > >> > >> Does not help when the anchor name needs to vary as well. That's where I > >> will use a #define to customize the template on include. > >> > >>> > >>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS > >>> and all the #define stuff. > >> > >> You still didn't address my question. Should I share my version to make > >> the problem clearer? But I thought I explained this in various shades > >> already. > > > > Yes, if I am looking at the wrong patches, please point me to the > > correct series, or push a tree somewhere. > > > > Please have a look at > https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e OK that looks a lot better to me. We can go with that until we come up with something better. There has been a long-standing request to support common parts of images. I am thinking something like this: common_part: common-part { template; // indic
Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox
Sorry for being late to the party, +cc Jose who maintains DEN0118 On Mon, Jun 19, 2023 at 11:16:53AM -0500, Jassi Brar wrote: > Hi Michal, > > On Mon, 19 Jun 2023 at 10:02, Michal Simek wrote: > > > > Hi Jassi, > > > > On 5/31/23 07:28, jaswinder.si...@linaro.org wrote: > > > From: Jassi Brar > > > > > > Introduce support for mtd backed storage for FWU feature and enable it on > > > Synquacer platform based DeveloperBox. > > > > > > This revision is rebased onto patchset that trims the FWU api > > > > > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/ > > > > . > > > Firstly I can generate 2 images per one bank which should be pretty much > > regular > > capsule update for 2 images. I would expect this should still work. > > > > And then I tried 2 banks with 2 images and fwu_gen_alt_info_from_mtd() > > generated > > this description for DFU > > > > mtd nor0=bank0 raw 232 8;bank1 raw 27a 8000&mtd nor0=bank0 raw > > 23a 400;bank1 raw 282 400 > > > > If you look at size in second entry you will see that it is 8000 instead of > > 8 because it is the same image. That's why curious if you have tested > > any > > scenario like this. > > > I had, and have, strong doubts about the practicality of 2 > images/bank. There aren't enough specification details to explain how > only 1-out-of-N images could be updated. And if we always update all > images in a bank together, we might as well have them as one composite > image. I never got satisfactory clarification from designers and > implementers. So, sorry, I can't defend that scenario with my limited > knowledge. This is intentionally left out, as we consider it a platform policy. For example you could update a single bank and copy over the remaining firmware images from a different ban. There's nothing on the spec that prohibits you from doing so, but I personally think it's a bad idea. Keep in mind there's a document hosted here[0] which explains the update flow and documents what we have as code in U-Boot. As far as individual firmware components go now, do you have any useful usecase? The general guidance of [0] is construct a firmware image, only update the components you want while leaving the rest on the same revisions and update the entire firmware. The reason is that firmware Updating a single image of another bank is not as easy as it sounds. Firmware components nowadays, whether we like it or not, depend on each other. Since firmware updates are not so often and fast, we didn't see any gains from over complicating the spec and explicitly describe that case, while dealing with firmware component compatibility at the same time. > > > Next part which I want to take a look is practicality of > > CONFIG_FWU_NUM_BANKS > > and CONFIG_FWU_NUM_IMAGES_PER_BANK because it pretty much enforcing number > > of > > banks and images for every platform and prevent creating one u-boot which > > works > > on different boards and just use information from mdata. > > DEN0118 doesn't show any field with this information but do you think that > > would > > be possible to extract that information from there based on for example > > reserved > > or accepted field? > > > Unfortunately the DEN0118 spec doesn't leave any 'don't care' bits in > 'accepted' or 'reserved' fields, all unused bits Must-Be-Zero. If we > use any bit, we'll be in violation of the spec. Yes this is unfortunate. We did have similar concerns on when drafting the spec, however we never had a solid usecase to justify this. Arm and Linaro and working on a v2 (which we try to make compatible with v1) which addresses this shortcoming. Maybe Jose can chime in. > > However, we can do CRC32 calculations by varying NUM_IMAGES_PER_BANK > and NUM_BANKS and find the value pair for which the crc32 field > matches! > For limiting check-loops and finding corrupted metadata, the .config > can carry upper limits on both the options, say > MAX_NUM_IMAGES_PER_BANK=5 and MAX_NUM_BANKS=10 for the most special > scenario. If we find the approach acceptable, I can cook a patch as > proof-of-concept. > > cheers. [0] https://gitlab.com/Linaro/trustedsubstrate/mbfw/uploads/3d0d7d11ca9874dc9115616b418aa330/mbfw.pdf Thanks /Ilias
Re: [BUG] bind command leads to invalid state where plaform data is NULL
Hi Heinrich, On Mon, 19 Jun 2023 at 18:51, Heinrich Schuchardt wrote: > > On 6/19/23 14:57, Simon Glass wrote: > > I suggest a simple device that needs no setup. The original commit[1] > > suggests using USB - does that worK? > > > > Regards, > > Simon > > > > [1] 49c752c93a78 ("cmd: Add bind/unbind commands to bind a device to a > > driver from the command line") > > I see devices listed after bind but I do not see any device that could > be used after binding it with the bind command. It might be worth asking the author. If there is any parent/uclass/device priv/plat then it won't be set up by this command. > > Here is another instance where using the bind command leads to a crash > (on pine64-lts_defconfig). > > Another question: > Is it correct that two devices have the same name? It shouldn't cause any problems since we don't normally reference devices by name. But it could be confusing for the user if there are two children of the same device with the same name. > > => dm tree > Class Index Probed Driver Name > -- > watchdog 0 [ + ] sunxi_wdt | |-- watchdog@1c20ca0 > sysreset 0 [ ] wdt_reboot | | `-- watchdog@1c20ca0 > => unbind sysreset 0 > => bind watchdog 0 wdt_reboot > => reset > resetting ... > "Synchronous Abort" handler, esr 0x9604, far 0xea06ea70 > elr: 4a044054 lr : 4a034c94 (reloc) > elr: bdf8d054 lr : bdf7dc94 > x0 : x1 : > x2 : bdf7dc6c x3 : ea06ea08 > x4 : b9f1ec78 x5 : b9f2cbd0 > x6 : 0072 x7 : b9f1ed30 > x8 : 0040 x9 : fff0 > x10: 0006 x11: 0001869f > x12: b9f1eec8 x13: b9f1efd0 > x14: x15: b9f1e79f > x16: bdf7dc6c x17: > x18: b9f28d90 x19: 0001 > x20: 0001 x21: > x22: b9f38680 x23: 0001 > x24: bdff4f54 x25: > x26: b9f2d2d0 x27: > x28: x29: b9f1ecd0 > > Code: a8c27bfd d65f03c0 d65f03c0 f943 (f9403463) > > The crash is in do_reset(). Looking at the device, it needs plat data and uses it in wdt_reboot_of_to_plat(). Regards, Simon
Re: [PATCH] axi: fix a warning
On Mon, 19 Jun 2023 at 21:36, Sergei Antonov wrote: > > Fix an enum/integer mismatch encountered in 'sandbox_defconfig' build. > > .../u-boot/drivers/axi/axi-emul-uclass.c:16:5: warning: conflicting types for > ‘axi_sandbox_get_emul’ due to enum/integer mismatch; have ‘int(struct udevice > *, ulong, enum axi_size_t, struct udevice **)’ {aka ‘int(struct udevice *, > long unsigned int, enum axi_size_t, struct udevice **)’} > [-Wenum-int-mismatch] >16 | int axi_sandbox_get_emul(struct udevice *bus, ulong address, > | ^~~~ > In file included from .../u-boot/drivers/axi/axi-emul-uclass.c:14: > .../u-boot/arch/sandbox/include/asm/axi.h:48:5: note: previous declaration of > ‘axi_sandbox_get_emul’ with type ‘int(struct udevice *, ulong, uint, struct > udevice **)’ {aka ‘int(struct udevice *, long unsigned int, unsigned int, > struct udevice **)’} >48 | int axi_sandbox_get_emul(struct udevice *bus, ulong address, uint > length, > | ^~~~ > > Make function declaration match function definition. > > Cc: Mario Six > Signed-off-by: Sergei Antonov > --- > arch/sandbox/include/asm/axi.h | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
Hi Xavier, On Wed, 14 Jun 2023 at 09:40, Xavier Drudis Ferran wrote: > > > Thanks for explaining, Simon Glass. > > Can someone please stop me if I'm splitting hairs or bikeshedding or > something ? I guess we agree both checking for null or UCLASS_BOOTDEV > would work right now but we are looking for what's more future-proof. > > El Tue, Jun 13, 2023 at 09:12:30PM +0100, Simon Glass deia: > > Hi Xavier, > > > > On Tue, 13 Jun 2023 at 17:04, Xavier Drudis Ferran > > wrote: > > > > > > El Tue, Jun 13, 2023 at 03:58:22PM +0100, Simon Glass deia: > > > > > > > > Yes that's right. So 'usb info' should ignore UCLASS_BOOTDEV devices. > > > > > > That's a possibility, yes. It should work until someone adds another > > > device there for some other purpose. > > > > > > > That is better than checking for the NULL pointer. > > > > > > > > > > Why? What's wrong about checking for null ? > > > Or maybe checking for both not null and not UCLASS_BOOTDEV ? > > > > > > Not that I care too much, just to understand your reasoning. > > > > Well, devices may have something attached there, so it may be > > non-NULL, but point to a different struct from the expected one. > > > > Yes. That is possible. How likely ? > > That "there" is dev_get_parent_priv(). If I understand the driver > model, those devices shouldn't put things there themselves, it should > be their parent who puts stuff there for them. And the parent should > be an usb_device->dev (because of the recursive code). So what other > struct would such a parent put in a child parent_priv_ ? Yes, whatever > it wants, but I mean, isn't it likely to assume the child would be > "adopted" with null as parent_priv_ or a "natural child" with a usb_device > in parent_priv_ ? > > I did a very rough search > > grep -rIE 'UCLASS_(BLK|BOOTDEV|USB_EMUL)' . |grep -F .id |cut -f1 -d: |xargs > -n 1 grep -l per_child_auto > ./drivers/usb/emul/usb-emul-uclass.c > > Which seems to suggest only UCLASS_USB_EMUL would have parent_priv_, > and that would be an usb_device, which the current code does not want > to recurse anyway. (dev_set_parent_priv() is almost never called). > > It is also possible that one day a device that is not UCLASS_BLK, > UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage > device (just imagine a future system similar to bootstd for firmware > updates, trust material, etc.). Is it likely to have a struct in > parent_priv_ that is not a usb_device ? > > So which is more likely to survive future changes ? > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL > > - checking for parent_priv_ not null and not UCLASS_USB_EMUL and not > UCLASS_BLK > (my patch, overcautious ?) > > - checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL) > (Simon Glass' idea) > > - checking for not UCLASS_BLK and not UCLASS_BOOTDEV and not UCLASS_USB_EMUL >and parent_priv_ not null Really the parent_priv thing is a separate issue, a side effect of something having a UCLASS_USB parent. The key point here is that we cannot iterate down into a bootdev device looking for USB devices. So we should use that as the check, since it is the most direct check. > > > > > > > Or can we check for recursible devices somehow ? > > > Maybe flag them or something ? > > > > > > Why is better to state all devices are recursible except some UCLASSes > > > (meaning they can have stuff that needs listed in usb info - or > > > likewise usb tree -) instead of stating that some closed set are > > > recursible ? > > > > > > > For USB we can have lots of different types of devices as children, so > > it would be a pain to enumerate them all. At least that's how I see > > it. > > > > We can have lots of devices as children, but those do get listed > before the recursive call. How many of those can have children that > we have to list too, i.e. how many of those do we want to recurse > into ? > > I can only think of usb hubs (maybe some node for multifunction > devices too ???). Maybe I'm not understanding how U-Boot works with > USB devices... but it looks like it would be enough to look for > UCLASS_USB_HUB, then recursive call, else no recursion. I mean instead of > > cmd/usb.c : usb_show_tree_graph() : > > if ((device_get_uclass_id( child ) != UCLASS_USB_EMUL) && > (device_get_uclass_id( child ) != UCLASS_BOOTDEV) && > (device_get_uclass_id( child ) != UCLASS_BLK)) { > usb_show_tree_graph(udev, pre); > pre[index] = 0; > } > > we could simply have > > if (device_get_uclass_id( dev->dev ) == UCLASS_USB_HUB) { > usb_show_tree_graph(udev, pre); > pre[index] = 0; > } > > (or put the condition directly before the for loop) > > Or can we have an UCLASS_USB_EMUL, UCLASS_BLK or UCLASS_BOOTDEV as > direct child of an UCLASS_USB_HUB ??? > > Am I opening any cans of worms ? >From my mem
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 11:42, Michal Simek wrote: On 6/20/23 11:23, Marek Vasut wrote: On 6/20/23 08:36, Michal Simek wrote: On 6/19/23 19:04, Eugen Hristev wrote: On 6/19/23 19:07, Marek Vasut wrote: On 6/19/23 15:26, Eugen Hristev wrote: On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: [ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/core.c | 50 +++-- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..8702a54efa 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - mdelay(100); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* Hello Venkatesh, Michal, I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I noticed that you removed the code that resets the PHYs in this patch hence DWC3 is no longer starting in my case. Was this intentional with this patch ? All of these patches are NAK until the DWC3 is synchronized with Linux. Picking random DWC3 patches and ignoring other fixes will turn the whole driver into an unmaintainable mess and make the sync that much harder in the future. I spent enormous amount of my spare time trying to explain to Xilinx how to do that mostly automatically, but that was all ignored or countered with reason after reason why this cannot be done, but as far as I can tell, nobody in Xilinx actually tried the proposal. Hence, NAK Hence, no need to worry these patches will be applied in their current state. Hi Marek, that's fine. No argument from my side. What I wanted to actually tell/ask , is the fact that this patch actually helps in my case, just that it breaks something else, and I wanted to get more info from the patch authors. I am experiencing some situations where dwc3 does not correctly start unless I add some manual delays here and there, and I am trying to see why. It is not just about dwc3. There are other parts which are ported from Linux kernel and are out of sync from Linux kernel for quite a long time. Another example is xhci - kernel 3.4. I am little bit worried that the whole usb stack is out of sync. AMD/Xilinx had the opportunity and means to fix that worry, mostly in an automated manner, but chose to
Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
On 6/20/23 11:17, Xavier Drudis Ferran wrote: El Mon, Jun 19, 2023 at 11:49:18PM +0200, Marek Vasut deia: On 6/19/23 12:12, Xavier Drudis Ferran wrote: It seems the email addresses are being constantly corrupted in each email. This time the ML address is wrong and missing an e at the end. There is some e@ nonexistent address which I have to keep removing. Yes, that's my fault. I'm sorry. I apologize to you and others. I resent my mail with the proper address. Please just look for my mail with the wrong address and delete it from your mail archive to prevent further such problems. You can reply to the other mail I sent (June 19th), because it has the same content, just with an added apology. Sorry again. That's fine When DISTRO_DEFAULTS is not set, the default environment has bootcmd=bootflow That is not right, on $randomboard I picked the bootcmd is something else. And how default is your default environment for your $randomboard ? Default, see: $ git grep CONFIG_BOOTCOMMAND configs/ Almost half the configs/* redefine CONFIG_BOOTCOMMAND (524/1268) When DISTRO_DEFAULTS is not set, that makes BOOTSTD_BOOTCOMMAND default to y and the default for BOOTCMD is not "run distro_boootcmd", but "bootflow scan" or (for sandbox) "bootflow scan -lb". When there's bootcmd at all. But this is only the default for the default environment. It can be overriden and the Kconfig is not exactly simple. An extract: next branch: arch/Arm/Kconfig: config ARCH_ROCKCHIP [...] imply BOOTSTD_DEFAULTS [...] cmd/Kconfig: config CMD_BOOTFLOW bool "bootflow" depends on BOOTSTD default y [...] config CMD_BOOTFLOW_FULL bool "bootflow - extract subcommands" depends on BOOTSTD_FULL default y [...] boot/Kconfig: config BOOT_DEFAULTS bool # Common defaults for standard boot and distroboot imply USE_BOOTCOMMAND [...] config BOOTSTD bool "Standard boot support" default y [...] config BOOTSTD_FULL bool "Enhanced features for standard boot" default y if SANDBOX [...] if BOOTSTD [...] config BOOTSTD_DEFAULTS bool "Select some common defaults for standard boot" depends on BOOTSTD imply USE_BOOTCOMMAND select BOOT_DEFAULTS select BOOTMETH_DISTRO [...] config BOOTSTD_BOOTCOMMAND bool "Use bootstd to boot" default y if !DISTRO_DEFAULTS [...] [...] endif [...] config DISTRO_DEFAULTS bool "Select defaults suitable for booting general purpose Linux distributions" select BOOT_DEFAULTS [...] config BOOTCOMMAND string "bootcmd value" depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE default "bootflow scan -lb" if BOOTSTD_DEFAULTS && CMD_BOOTFLOW_FULL default "bootflow scan" if BOOTSTD_DEFAULTS && !CMD_BOOTFLOW_FULL default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && DISTRO_DEFAULTS Does this happen if you set empty bootcmd ('=> setenv bootcmd 'echo hello' for example), then 'saveenv' , then 'reset' , then drop into U-Boot shell and run 'usb reset ; usb info' too ? I haven't tested it. If bootflow scan is not run it might not happen. So, what is the minimal test case ? I have been asking for that for a while. Someone has to hang the UCLASS_BOOTDEV on the usb mass storage device, for it to fail. But as far as I know the idea is to make bootflow the default in more and more cases. You'll always be able to avoid it running in your board by setting your own environment at runtime or changing the configuration, yes, but what's the point ? I thought that failing one scenario was enough to fix things. When one finds a bug it tries to help others to reproduce it. When others help the bug finder to run other scenarios that don't have the bug, what's that useful for ? Note that it won't fail if the boot succeeds, because then you won't have a shell to run usb info/tree. It won't fail if usb is not in boot_targets. It won't fail if there's no mass storage device connected to usb when bootflow scan is run... But I still think the failing case is worth fixing. Someone may be wondering why bootflow fails, run usb info and find a reset, when setting up a new board, or trying to boot from the wrong usb stick after the system partition has been corrupted, or whatever. It's not something that breaks any board in production, but it's not something to leave forever broken. In theory a null pointer dereference might be used by some attacker, but in this case I don't really see any useful attack, maybe it's my lack of imagination. So I'm not claiming it's a severe bug. It's just a normal bug that needs fixing when possible. Or are you trying to hint that the solution shouldn't be changing cmd/usb.c but cleaning up the UCLASS_BOOTDEVs after bootflow scan somehow ? I would really like a minimal test case.
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 11:23, Marek Vasut wrote: On 6/20/23 08:36, Michal Simek wrote: On 6/19/23 19:04, Eugen Hristev wrote: On 6/19/23 19:07, Marek Vasut wrote: On 6/19/23 15:26, Eugen Hristev wrote: On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: [ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/core.c | 50 +++-- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..8702a54efa 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - mdelay(100); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* Hello Venkatesh, Michal, I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I noticed that you removed the code that resets the PHYs in this patch hence DWC3 is no longer starting in my case. Was this intentional with this patch ? All of these patches are NAK until the DWC3 is synchronized with Linux. Picking random DWC3 patches and ignoring other fixes will turn the whole driver into an unmaintainable mess and make the sync that much harder in the future. I spent enormous amount of my spare time trying to explain to Xilinx how to do that mostly automatically, but that was all ignored or countered with reason after reason why this cannot be done, but as far as I can tell, nobody in Xilinx actually tried the proposal. Hence, NAK Hence, no need to worry these patches will be applied in their current state. Hi Marek, that's fine. No argument from my side. What I wanted to actually tell/ask , is the fact that this patch actually helps in my case, just that it breaks something else, and I wanted to get more info from the patch authors. I am experiencing some situations where dwc3 does not correctly start unless I add some manual delays here and there, and I am trying to see why. It is not just about dwc3. There are other parts which are ported from Linux kernel and are out of sync from Linux kernel for quite a long time. Another example is xhci - kernel 3.4. I am little bit worried that the whole usb stack is out of sync. AMD/Xilinx had the opportunity and means to fix that worry, mostly in an automated manner, but chose to ignore all input and be unhelpful. Too bad. It is not
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
On 6/20/23 09:03, Xavier Drudis Ferran wrote: El Tue, Jun 20, 2023 at 02:50:48AM +0200, Marek Vasut deia: On 6/13/23 08:52, Xavier Drudis Ferran wrote: U-Boot TPL 2023.07-rc2-00144-g497967f1ee (Jun 12 2023 - 11:15:47) Next is already at rc4 , what's this rc2 ? It's a test I did last week (June 12th). What do you think has changed in next between rc2 and rc4 so that this shouldn't happen now ? The beginning of the email states: " Ok. New test. This uses yesterday morning's next branch. commit 5b589e139620214f " So, that is not the case ? Also, commit 497967f1ee does not exist in upstream U-Boot, was this some patched U-Boot tree ? My last patch (sent yesterday) was tested with the next branch as of yesterday morning. But you can test it yourself with any version you like. Do I have to send the logs of each test I do to the list every time ? Ideally the claims you make about what you tested and logs from the test should match, that would be a good starting point. I thought Simon Glass reply last week to the mail you quoted already showed agreement that the issue exists, and the adding of the UCLASS_BOOTDEV device is per design, so cmd/usb.c needs fixing to deal with this change. I am not disputing that. What bothers me is the still missing consistent test case, esp. if this is a fix which should be added this late in release.
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 08:36, Michal Simek wrote: On 6/19/23 19:04, Eugen Hristev wrote: On 6/19/23 19:07, Marek Vasut wrote: On 6/19/23 15:26, Eugen Hristev wrote: On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote: [ Felipe: Ported from Linux kernel commit f59dcab17629 ("usb: dwc3: core: improve reset sequence") ] According to Synopsys Databook, we shouldn't be relying on GCTL.CORESOFTRESET bit as that's only for debugging purposes. Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode. Host side block will be reset by XHCI driver if necessary. Note that this reduces amount of time spent on dwc3_probe() by a long margin. We're still gonna wait for reset to finish for a long time (default to 1ms max), but tests show that the reset polling loop executed at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000 times in a row). Without proper core reset, observing random issues like when the USB(DWC3) is in device mode, the host device is not able to detect the USB device. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/usb/dwc3/core.c | 50 +++-- 1 file changed, 18 insertions(+), 32 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 49f6a1900b..8702a54efa 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode) static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int retries = 1000; - /* Before Resetting PHY, put Core in Reset */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg |= DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); - - /* Assert USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Assert USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); - - mdelay(100); - - /* Clear USB3 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); - reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); - - /* Clear USB2 PHY reset */ - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); - reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + /* + * We're resetting only the device side because, if we're in host mode, + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode, then we can return early. + */ + if (dwc->dr_mode == USB_DR_MODE_HOST) + return 0; - mdelay(100); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + dwc3_writel(dwc->regs, DWC3_DCTL, reg); - /* After PHYs are stable we can take Core out of reset state */ - reg = dwc3_readl(dwc->regs, DWC3_GCTL); - reg &= ~DWC3_GCTL_CORESOFTRESET; - dwc3_writel(dwc->regs, DWC3_GCTL, reg); + do { + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + if (!(reg & DWC3_DCTL_CSFTRST)) + return 0; + udelay(1); + } while (--retries); - return 0; + return -ETIMEDOUT; } /* Hello Venkatesh, Michal, I randomly found this patch while testing the Dwc3 on rockchip RK3588 , I noticed that you removed the code that resets the PHYs in this patch hence DWC3 is no longer starting in my case. Was this intentional with this patch ? All of these patches are NAK until the DWC3 is synchronized with Linux. Picking random DWC3 patches and ignoring other fixes will turn the whole driver into an unmaintainable mess and make the sync that much harder in the future. I spent enormous amount of my spare time trying to explain to Xilinx how to do that mostly automatically, but that was all ignored or countered with reason after reason why this cannot be done, but as far as I can tell, nobody in Xilinx actually tried the proposal. Hence, NAK Hence, no need to worry these patches will be applied in their current state. Hi Marek, that's fine. No argument from my side. What I wanted to actually tell/ask , is the fact that this patch actually helps in my case, just that it breaks something else, and I wanted to get more info from the patch authors. I am experiencing some situations where dwc3 does not correctly start unless I add some manual delays here and there, and I am trying to see why. It is not just about dwc3. There are other parts which are ported from Linux kernel and are out of sync from Linux kernel for quite a long time. Another example is xhci - kernel 3.4. I am little bit worried that the whole usb stack is out of sync. AMD/Xilinx had the opportunity and means to fix that worry, mostly in an automated manner, but chose to ignore all input and be unhelpful. Too bad.
Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
El Mon, Jun 19, 2023 at 11:49:18PM +0200, Marek Vasut deia: > On 6/19/23 12:12, Xavier Drudis Ferran wrote: > > It seems the email addresses are being constantly corrupted in each email. > This time the ML address is wrong and missing an e at the end. There is some > e@ nonexistent address which I have to keep removing. > Yes, that's my fault. I'm sorry. I apologize to you and others. I resent my mail with the proper address. Please just look for my mail with the wrong address and delete it from your mail archive to prevent further such problems. You can reply to the other mail I sent (June 19th), because it has the same content, just with an added apology. Sorry again. > > When DISTRO_DEFAULTS is not set, the default environment has > > bootcmd=bootflow > > That is not right, on $randomboard I picked the bootcmd is something else. > And how default is your default environment for your $randomboard ? Almost half the configs/* redefine CONFIG_BOOTCOMMAND (524/1268) When DISTRO_DEFAULTS is not set, that makes BOOTSTD_BOOTCOMMAND default to y and the default for BOOTCMD is not "run distro_boootcmd", but "bootflow scan" or (for sandbox) "bootflow scan -lb". When there's bootcmd at all. But this is only the default for the default environment. It can be overriden and the Kconfig is not exactly simple. An extract: next branch: arch/Arm/Kconfig: config ARCH_ROCKCHIP [...] imply BOOTSTD_DEFAULTS [...] cmd/Kconfig: config CMD_BOOTFLOW bool "bootflow" depends on BOOTSTD default y [...] config CMD_BOOTFLOW_FULL bool "bootflow - extract subcommands" depends on BOOTSTD_FULL default y [...] boot/Kconfig: config BOOT_DEFAULTS bool # Common defaults for standard boot and distroboot imply USE_BOOTCOMMAND [...] config BOOTSTD bool "Standard boot support" default y [...] config BOOTSTD_FULL bool "Enhanced features for standard boot" default y if SANDBOX [...] if BOOTSTD [...] config BOOTSTD_DEFAULTS bool "Select some common defaults for standard boot" depends on BOOTSTD imply USE_BOOTCOMMAND select BOOT_DEFAULTS select BOOTMETH_DISTRO [...] config BOOTSTD_BOOTCOMMAND bool "Use bootstd to boot" default y if !DISTRO_DEFAULTS [...] [...] endif [...] config DISTRO_DEFAULTS bool "Select defaults suitable for booting general purpose Linux distributions" select BOOT_DEFAULTS [...] config BOOTCOMMAND string "bootcmd value" depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE default "bootflow scan -lb" if BOOTSTD_DEFAULTS && CMD_BOOTFLOW_FULL default "bootflow scan" if BOOTSTD_DEFAULTS && !CMD_BOOTFLOW_FULL default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && DISTRO_DEFAULTS > > Does this happen if you set empty bootcmd ('=> setenv bootcmd 'echo hello' > for example), then 'saveenv' , then 'reset' , then drop into U-Boot shell > and run 'usb reset ; usb info' too ? > I haven't tested it. If bootflow scan is not run it might not happen. Someone has to hang the UCLASS_BOOTDEV on the usb mass storage device, for it to fail. But as far as I know the idea is to make bootflow the default in more and more cases. You'll always be able to avoid it running in your board by setting your own environment at runtime or changing the configuration, yes, but what's the point ? I thought that failing one scenario was enough to fix things. When one finds a bug it tries to help others to reproduce it. When others help the bug finder to run other scenarios that don't have the bug, what's that useful for ? Note that it won't fail if the boot succeeds, because then you won't have a shell to run usb info/tree. It won't fail if usb is not in boot_targets. It won't fail if there's no mass storage device connected to usb when bootflow scan is run... But I still think the failing case is worth fixing. Someone may be wondering why bootflow fails, run usb info and find a reset, when setting up a new board, or trying to boot from the wrong usb stick after the system partition has been corrupted, or whatever. It's not something that breaks any board in production, but it's not something to leave forever broken. In theory a null pointer dereference might be used by some attacker, but in this case I don't really see any useful attack, maybe it's my lack of imagination. So I'm not claiming it's a severe bug. It's just a normal bug that needs fixing when possible. Or are you trying to hint that the solution shouldn't be changing cmd/usb.c but cleaning up the UCLASS_BOOTDEVs after bootflow scan somehow ? Or I should change the commit message because the point is not so much what's the default environment or the default default environment, but simply that bootflow scan is run with an usb mass storage device connected and no boot content pres
[PATCH v2 19/19] x86: coral: Adjust various config options
Add ms so it is easier to search for tables in memory. Expand the command-line and print buffers so that we can deal with the very long ChromeOS command lines. (typically 700 characters). Enable BOOTSTD_FULL to get the full set of standard-boot options. Replace the existing manual script with 'bootflow scan', since it can find and boot the OS. Finally, expand the malloc() space so we can read large kernels into a bootflow. Signed-off-by: Simon Glass --- Changes in v2: - Drop mention of NVMe support configs/chromebook_coral_defconfig | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configs/chromebook_coral_defconfig b/configs/chromebook_coral_defconfig index f5995f22004e..fe61153b93d8 100644 --- a/configs/chromebook_coral_defconfig +++ b/configs/chromebook_coral_defconfig @@ -1,5 +1,6 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x111 +CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SYS_MALLOC_F_LEN=0x3d00 CONFIG_NR_DRAM_BANKS=8 CONFIG_MAX_CPUS=8 @@ -22,6 +23,7 @@ CONFIG_X86_OFFSET_U_BOOT=0xffd0 CONFIG_X86_OFFSET_SPL=0xffe8 CONFIG_INTEL_ACPIGEN=y CONFIG_INTEL_GENERIC_WIFI=y +CONFIG_BOOTSTD_FULL=y CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_CHROMEOS=y CONFIG_BOOTSTAGE=y @@ -33,8 +35,10 @@ CONFIG_BOOTSTAGE_STASH=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS_SUBST=y CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; read mmc 0:2 10 0 80; setexpr loader *001004f0; setexpr size *00100518; setexpr blocks $size / 200; read mmc 0:2 10 80 $blocks; setexpr setup $loader - 1000; setexpr cmdline_ptr $loader - 2000; setexpr.s cmdline *$cmdline_ptr; setexpr cmdline gsub %U ${uuid}; if part uuid mmc 0:2 uuid; then zboot start 10 0 0 0 $setup cmdline; zboot load; zboot setup; zboot dump; zboot go;fi" +CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; bootflow scan -lb" CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_LOG=y +CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_BLOBLIST=y @@ -52,9 +56,11 @@ CONFIG_SPL_POWER=y CONFIG_TPL_SYS_MALLOC_SIMPLE=y CONFIG_TPL_POWER=y CONFIG_HUSH_PARSER=y -CONFIG_SYS_PBSIZE=532 +CONFIG_SYS_CBSIZE=1024 +CONFIG_SYS_PBSIZE=1024 CONFIG_CMD_CPU=y CONFIG_CMD_PMC=y +CONFIG_CMD_MEM_SEARCH=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_PART=y -- 2.41.0.162.gfafddb0af9-goog
[PATCH v2 18/19] x86: coreboot: Adjust various config options
Drop IDE since this is not widely used anymore. Add NVME since it is becoming more popular. Add ms so it is easier to search for tables in memory. Expand the command-line and print buffers so that we can deal with the very long ChromeOS command lines. (typically 700 characters). Enable BOOTSTD_FULL to get the full set up standard-boot options. Finally, expand the malloc() space so we can read large kernels into a bootflow. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot_defconfig | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 058caf008f9a..e650fca572f9 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -1,5 +1,6 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x111 +CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="coreboot" @@ -8,12 +9,11 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_LOG=y @@ -23,9 +23,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y CONFIG_HUSH_PARSER=y -CONFIG_SYS_PBSIZE=532 -CONFIG_CMD_MEM_SEARCH=y -CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_USB=y @@ -53,13 +50,8 @@ CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_ACPIGEN is not set -CONFIG_SYS_IDE_MAXDEVICE=4 -CONFIG_SYS_ATA_DATA_OFFSET=0 -CONFIG_SYS_ATA_REG_OFFSET=0 -CONFIG_SYS_ATA_ALT_OFFSET=0 -CONFIG_ATAPI=y -CONFIG_LBA48=y -CONFIG_SYS_64BIT_LBA=y +CONFIG_MISC=y +CONFIG_NVMEM=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SOUND=y -- 2.41.0.162.gfafddb0af9-goog
[PATCH v2 17/19] bootstd: Add a simple bootmeth for ChromiumOS
It is possible to boot x86-based ChromeOS machines by parsing a table and locating the kernel and command line. Add a bootmeth for this. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) boot/Kconfig | 11 ++ boot/Makefile| 1 + boot/bootmeth_cros.c | 212 +++ configs/tools-only_defconfig | 1 + 4 files changed, 225 insertions(+) create mode 100644 boot/bootmeth_cros.c diff --git a/boot/Kconfig b/boot/Kconfig index eea5ed6040ff..98eb2ca94c8e 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -463,6 +463,17 @@ config BOOTMETH_GLOBAL EFI bootmgr, since they take full control over which bootdevs are selected to boot. +config BOOTMETH_CROS + bool "Bootdev support for Chromium OS" + depends on X86 || SANDBOX + default y + help + Enables support for booting Chromium OS using bootdevs. This uses the + kernel A slot and obtains the kernel command line from the parameters + provided there. + + Note that only x86 devices are supported at present. + config BOOTMETH_EXTLINUX bool "Bootdev support for extlinux boot" select PXE_UTILS diff --git a/boot/Makefile b/boot/Makefile index f94c31d922de..6e4cdbd4ce28 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EXTLINUX) += bootmeth_extlinux.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EXTLINUX_PXE) += bootmeth_pxe.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o +obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_CROS) += bootmeth_cros.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c new file mode 100644 index ..aa19ae097f56 --- /dev/null +++ b/boot/bootmeth_cros.c @@ -0,0 +1,212 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Bootmethod for ChromiumOS + * + * Copyright 2023 Google LLC + * Written by Simon Glass + */ + +#define LOG_CATEGORY UCLASS_BOOTSTD + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#ifdef CONFIG_X86 +#include +#endif +#include + +enum { + /* Offsets in the kernel-partition header */ + KERN_START = 0x4f0, + KERN_SIZE = 0x518, + + SETUP_OFFSET= 0x1000, /* bytes before base */ + CMDLINE_OFFSET = 0x2000, /* bytes before base */ + OFFSET_BASE = 0x10, /* assumed kernel load-address */ +}; + +static int cros_check(struct udevice *dev, struct bootflow_iter *iter) +{ + /* This only works on block and network devices */ + if (bootflow_iter_check_blk(iter)) + return log_msg_ret("blk", -ENOTSUPP); + + return 0; +} + +static int copy_cmdline(const char *from, const char *uuid, char **bufp) +{ + const int maxlen = 2048; + char buf[maxlen]; + char *cmd, *to, *end; + int len; + + /* Allow space for cmdline + UUID */ + len = strnlen(from, sizeof(buf)); + if (len >= maxlen) + return -E2BIG; + + log_debug("uuid %d %s\n", uuid ? (int)strlen(uuid) : 0, uuid); + for (to = buf, end = buf + maxlen - UUID_STR_LEN - 1; *from; from++) { + if (to >= end) + return -E2BIG; + if (from[0] == '%' && from[1] == 'U' && uuid && + strlen(uuid) == UUID_STR_LEN) { + strcpy(to, uuid); + to += UUID_STR_LEN; + from++; + } else { + *to++ = *from; + } + } + *to = '\0'; + len = to - buf; + cmd = strdup(buf); + if (!cmd) + return -ENOMEM; + free(*bufp); + *bufp = cmd; + + return 0; +} + +static int cros_read_bootflow(struct udevice *dev, struct bootflow *bflow) +{ + struct blk_desc *desc = dev_get_uclass_plat(bflow->blk); + ulong base, start, size, setup, cmdline, num_blks, kern_base; + struct disk_partition info; + const char *uuid = NULL; + void *buf, *hdr; + int ret; + + log_debug("starting, part=%d\n", bflow->part); + + /* We consider the whole disk, not any one partition */ + if (bflow->part) + return log_msg_ret("max", -ENOENT); + + /* Check partition 2 */ + ret = part_get_info(desc, 2, &info); + if (ret) + return log_msg_ret("part", ret); + + /* Make a buffer for the header information */ + num_blks = SZ_4K >> desc->log2blksz; + log_debug("Reading header, blk=%s, start=%lx, blocks=%lx\n", + bflow->blk->name, (ulong)info.start, num_blks); + hdr = memalign(SZ_1K, SZ_4K); + if (!hdr) + return l
[PATCH v2 14/19] bootstd: Support automatically setting Linux parameters
Some Linux parameters can be set automatically by U-Boot, if it knows the device being used. For example, since U-Boot knows the serial console being used, it can add parameters for earlycon and console. Add support for this. Note that this is an experimental feature and we will see how useful it turns out to be. It is very handy for ChromeOS, since otherwise it is very difficult to manually determine the UART address or port number, particularly in a script. Provide an example of how this is used with ChromeOS. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) boot/bootflow.c| 33 + cmd/bootflow.c | 5 ++- doc/usage/cmd/bootflow.rst | 75 +- include/bootflow.h | 12 ++ 4 files changed, 123 insertions(+), 2 deletions(-) diff --git a/boot/bootflow.c b/boot/bootflow.c index 8c649e8e66ca..81b5829d5b37 100644 --- a/boot/bootflow.c +++ b/boot/bootflow.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -854,3 +855,35 @@ int bootflow_cmdline_get_arg(struct bootflow *bflow, const char *arg, return ret; } + +int bootflow_cmdline_auto(struct bootflow *bflow, const char *arg) +{ + struct serial_device_info info; + char buf[50]; + int ret; + + ret = serial_getinfo(gd->cur_serial_dev, &info); + if (ret) + return ret; + + *buf = '\0'; + if (!strcmp("earlycon", arg)) { + snprintf(buf, sizeof(buf), +"uart8250,mmio32,%#lx,%dn8", info.addr, +info.baudrate); + } else if (!strcmp("console", arg)) { + snprintf(buf, sizeof(buf), +"ttyS0,%dn8", info.baudrate); + } + + if (!*buf) { + printf("Unknown param '%s\n", arg); + return -ENOENT; + } + + ret = bootflow_cmdline_set_arg(bflow, arg, buf, true); + if (ret) + return ret; + + return 0; +} diff --git a/cmd/bootflow.c b/cmd/bootflow.c index ab00e4a19e14..c0aa4f84fe8d 100644 --- a/cmd/bootflow.c +++ b/cmd/bootflow.c @@ -474,6 +474,9 @@ static int do_bootflow_cmdline(struct cmd_tbl *cmdtp, int flag, int argc, if (ret >= 0) printf("%.*s\n", ret, val); break; + case 'a': /* auto */ + ret = bootflow_cmdline_auto(bflow, arg); + break; } switch (ret) { case -E2BIG: @@ -508,7 +511,7 @@ static char bootflow_help_text[] = "bootflow info [-d] - show info on current bootflow (-d dump bootflow)\n" "bootflow boot - boot current bootflow (or first available if none selected)\n" "bootflow menu [-t] - show a menu of available bootflows\n" - "bootflow cmdline [set|get|clear|delete] [] - update cmdline"; + "bootflow cmdline [set|get|clear|delete|auto] [] - update cmdline"; #else "scan - boot first available bootflow\n"; #endif diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst index 07af789e6702..a8af1f8f6030 100644 --- a/doc/usage/cmd/bootflow.rst +++ b/doc/usage/cmd/bootflow.rst @@ -13,7 +13,7 @@ Synopis bootflow select [] bootflow info [-d] bootflow boot -bootflow cmdline [set|get|clear|delete] [] +bootflow cmdline [set|get|clear|delete|auto] [] Description --- @@ -218,6 +218,16 @@ To delete a parameter entirely, use:: bootflow cmdline delete +Automatic parameters are available in a very few cases. You can use these to +add parmeters where the value is known by U-Boot. For example:: + +bootflow cmdline auto earlycon +bootflow cmdline auto console + +can be used to set the early console (or console) to a suitable value so that +output appears on the serial port. This is only supported by the 16550 serial +driver so far. + Example --- @@ -450,6 +460,69 @@ Here is am example using the -e flag to see all errors:: (21 bootflows, 2 valid) U-Boot> +Here is an example of booting ChromeOS, adjusting the console beforehand. Note that +the cmdline is word-wrapped here and some parts of the command line are elided:: + +=> bootfl list +Showing all bootflows +Seq Method State UclassPart Name Filename +--- --- -- +0 cros ready nvme 0 5.10.153-20434-g98da1eb2c +1 efi ready nvme c nvme#0.blk#1.bootdev.part efi/boot/bootia32.efi +2 efi ready usb_mass_2 usb_mass_storage.lun0.boo efi/boot/bootia32.efi +--- --- -- +(3 bootflows, 3 valid) +=> bootfl sel 0 +=> bootfl inf +Name: 5.10.153-20434-g98da1eb2cf9d (chrom
[PATCH v2 16/19] x86: zimage: Export the function to obtain the cmdline
Allow reading the command line from a zimage, so that it can be recorded in the bootflow. Reviewed-by: Bin Meng Signed-off-by: Simon Glass --- (no changes since v1) arch/x86/include/asm/zimage.h | 10 ++ arch/x86/lib/zimage.c | 11 --- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h index 966d7224eb18..9ad74dc0b946 100644 --- a/arch/x86/include/asm/zimage.h +++ b/arch/x86/include/asm/zimage.h @@ -89,4 +89,14 @@ void zimage_dump(struct boot_params *base_ptr); int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size, ulong base, char *cmdline); +/* + * zimage_get_kernel_version() - Get the version string from a kernel + * + * @params: boot_params pointer + * @kernel_base: base address of kernel + * Return: Kernel version as a NUL-terminated string + */ +const char *zimage_get_kernel_version(struct boot_params *params, + void *kernel_base); + #endif diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c index 540d4d888bc7..062e3d3e3151 100644 --- a/arch/x86/lib/zimage.c +++ b/arch/x86/lib/zimage.c @@ -181,7 +181,7 @@ static int setup_device_tree(struct setup_header *hdr, const void *fdt_blob) return 0; } -static const char *get_kernel_version(struct boot_params *params, +const char *zimage_get_kernel_version(struct boot_params *params, void *kernel_base) { struct setup_header *hdr = ¶ms->hdr; @@ -189,10 +189,14 @@ static const char *get_kernel_version(struct boot_params *params, const char *s, *end; bootproto = get_boot_protocol(hdr, false); + log_debug("bootproto %x, hdr->setup_sects %x\n", bootproto, + hdr->setup_sects); if (bootproto < 0x0200 || hdr->setup_sects < 15) return NULL; /* sanity-check the kernel version in case it is missing */ + log_debug("hdr->kernel_version %x, str at %p\n", hdr->kernel_version, + kernel_base + hdr->kernel_version + 0x200); for (s = kernel_base + hdr->kernel_version + 0x200, end = s + 0x100; *s; s++) { if (!isprint(*s)) @@ -239,7 +243,7 @@ struct boot_params *load_zimage(char *image, unsigned long kernel_size, log_debug("Using boot protocol version %x.%02x\n", (bootproto & 0xff00) >> 8, bootproto & 0xff); - version = get_kernel_version(params, image); + version = zimage_get_kernel_version(params, image); if (version) printf("Linux kernel version %s\n", version); else @@ -728,7 +732,8 @@ void zimage_dump(struct boot_params *base_ptr) print_num("Real mode switch", hdr->realmode_swtch); print_num("Start sys seg", hdr->start_sys_seg); print_num("Kernel version", hdr->kernel_version); - version = get_kernel_version(base_ptr, (void *)state.bzimage_addr); + version = zimage_get_kernel_version(base_ptr, + (void *)state.bzimage_addr); if (version) printf(" @%p: %s\n", version, version); print_num("Type of loader", hdr->type_of_loader); -- 2.41.0.162.gfafddb0af9-goog
[PATCH v2 15/19] x86: Add a function to boot a zimage
Add a direct interface to booting a zimage, so that bootstd can call it without going through the command-line interface. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) arch/x86/include/asm/zimage.h | 17 arch/x86/lib/zimage.c | 82 ++- 2 files changed, 88 insertions(+), 11 deletions(-) diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h index 000b38ea8993..966d7224eb18 100644 --- a/arch/x86/include/asm/zimage.h +++ b/arch/x86/include/asm/zimage.h @@ -72,4 +72,21 @@ int setup_zimage(struct boot_params *setup_base, char *cmd_line, int auto_boot, */ void zimage_dump(struct boot_params *base_ptr); +/** + * zboot_start() - Boot a zimage + * + * Boot a zimage, given the component parts + * + * @addr: Address where the bzImage is moved before booting, either + * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR + * @base: Pointer to the boot parameters, typically at address + * DEFAULT_SETUP_BASE + * @initrd: Address of the initial ramdisk, or 0 if none + * @initrd_size: Size of the initial ramdisk, or 0 if none + * @cmdline: Command line to use for booting + * Return: -EFAULT on error (normally it does not return) + */ +int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size, + ulong base, char *cmdline); + #endif diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c index e5ea5129c1e9..540d4d888bc7 100644 --- a/arch/x86/lib/zimage.c +++ b/arch/x86/lib/zimage.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -442,8 +443,7 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, int argc, return 0; } -static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc, -char *const argv[]) +static int zboot_load(void) { struct boot_params *base_ptr; @@ -460,31 +460,51 @@ static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc, &state.load_address); if (!base_ptr) { puts("## Kernel loading failed ...\n"); - return CMD_RET_FAILURE; + return -EINVAL; } } state.base_ptr = base_ptr; - if (env_set_hex("zbootbase", (ulong)base_ptr) || + + return 0; +} + +static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc, +char *const argv[]) +{ + if (zboot_load()) + return CMD_RET_FAILURE; + + if (env_set_hex("zbootbase", map_to_sysmem(state.base_ptr)) || env_set_hex("zbootaddr", state.load_address)) return CMD_RET_FAILURE; return 0; } +static int zboot_setup(void) +{ + struct boot_params *base_ptr = state.base_ptr; + int ret; + + ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET, + 0, state.initrd_addr, state.initrd_size, + (ulong)state.cmdline); + if (ret) + return -EINVAL; + + return 0; +} + static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { struct boot_params *base_ptr = state.base_ptr; - int ret; if (!base_ptr) { printf("base is not set: use 'zboot load' first\n"); return CMD_RET_FAILURE; } - ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET, - 0, state.initrd_addr, state.initrd_size, - (ulong)state.cmdline); - if (ret) { + if (zboot_setup()) { puts("Setting up boot parameters failed ...\n"); return CMD_RET_FAILURE; } @@ -501,8 +521,7 @@ static int do_zboot_info(struct cmd_tbl *cmdtp, int flag, int argc, return 0; } -static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc, - char *const argv[]) +static int zboot_go(void) { struct boot_params *params = state.base_ptr; struct setup_header *hdr = ¶ms->hdr; @@ -522,11 +541,52 @@ static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc, /* we assume that the kernel is in place */ ret = boot_linux_kernel((ulong)state.base_ptr, entry, image_64bit); + + return ret; +} + +static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc, + char *const argv[]) +{ + int ret; + + ret = zboot_go(); printf("Kernel returned! (err=%d)\n", ret); return CMD_RET_FAILURE; } +int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size, + ulong base, char *cmdline) +{ + int ret; + + memset(&state, '\0', sizeof(state)); + + if (base) { + state.base_ptr = map_sysmem(base, 0); + state.load_address = addr; +
[PATCH v2 10/19] bootstd: Add a function to update a command line
The Linux command line consists of a number of words with optional values. At present U-Boot allows this to be changed using the bootargs environment variable. But this is quite painful, since the command line can be very long. Add a function which can adjust a single field in the command line, so that it is easier to make changes before booting. Signed-off-by: Simon Glass --- Changes in v2: - Add comment for copy_in() - Avoid multiplication on a boolean - Add a comment as to why @len is needed boot/bootflow.c | 190 +++ include/bootflow.h | 40 + test/boot/bootflow.c | 154 +++ 3 files changed, 384 insertions(+) diff --git a/boot/bootflow.c b/boot/bootflow.c index 62b7f45ab278..26f26aee38a3 100644 --- a/boot/bootflow.c +++ b/boot/bootflow.c @@ -611,3 +611,193 @@ static int on_bootargs(const char *name, const char *value, enum env_op op, U_BOOT_ENV_CALLBACK(bootargs, on_bootargs); #endif +/** + * copy_in() - Copy a string into a cmdline buffer + * + * @buf: Buffer to copy into + * @end: End of buffer (pointer to char after the end) + * @arg: String to copy from + * @len: Number of chars to copy from @arg (note that this is not usually the + * sane as strlen(arg) since the string may contain following arguments) + * @new_val: Value to put after arg, or BOOTFLOWCL_EMPTY to use an empty value + * with no '=' sign + * Returns: Number of chars written to @buf + */ +static int copy_in(char *buf, char *end, const char *arg, int len, + const char *new_val) +{ + char *to = buf; + + /* copy the arg name */ + if (to + len >= end) + return -E2BIG; + memcpy(to, arg, len); + to += len; + + if (new_val == BOOTFLOWCL_EMPTY) { + /* no value */ + } else { + bool need_quote = strchr(new_val, ' '); + len = strlen(new_val); + + /* need space for value, equals sign and maybe two quotes */ + if (to + 1 + (need_quote ? 2 : 0) + len >= end) + return -E2BIG; + *to++ = '='; + if (need_quote) + *to++ = '"'; + memcpy(to, new_val, len); + to += len; + if (need_quote) + *to++ = '"'; + } + + return to - buf; +} + +int cmdline_set_arg(char *buf, int maxlen, const char *cmdline, + const char *set_arg, const char *new_val, int *posp) +{ + bool found_arg = false; + const char *from; + char *to, *end; + int set_arg_len; + char empty = '\0'; + int ret; + + from = cmdline ?: ∅ + + /* check if the value has quotes inside */ + if (new_val && new_val != BOOTFLOWCL_EMPTY && strchr(new_val, '"')) + return -EBADF; + + set_arg_len = strlen(set_arg); + for (to = buf, end = buf + maxlen; *from;) { + const char *val, *arg_end, *val_end, *p; + bool in_quote; + + if (to >= end) + return -E2BIG; + while (*from == ' ') + from++; + if (!*from) + break; + + /* find the end of this arg */ + val = NULL; + arg_end = NULL; + val_end = NULL; + in_quote = false; + for (p = from;; p++) { + if (in_quote) { + if (!*p) + return -EINVAL; + if (*p == '"') + in_quote = false; + continue; + } + if (*p == '=') { + arg_end = p; + val = p + 1; + } else if (*p == '"') { + in_quote = true; + } else if (!*p || *p == ' ') { + val_end = p; + if (!arg_end) + arg_end = p; + break; + } + } + /* +* At this point val_end points to the end of the value, or the +* last char after the arg name, if there is no label. +* arg_end is the char after the arg name +* val points to the value, or NULL if there is none +* char after the value. +* +*fred=1234 +*^ ^^ ^ +* from || | +* / \\ +*arg_end val val_end +*/ + log_debug("from %s arg_end %ld val %ld val_end %ld\n", from, + (long)(arg_end - fr
[PATCH v2 12/19] x86: qemu: Create a little more room for U-Boot
We want to enable some of the more interesting bootstd features. Move SPL up to create some room for the larger U-Boot binary. Also disable microcode since this is not needed Signed-off-by: Simon Glass --- Changes in v2: - Add new patch to create a little more room for U-Boot on qemu-x86_64 configs/qemu-x86_64_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 870332a1e625..45df1e46fa38 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -6,13 +6,14 @@ CONFIG_ENV_SIZE=0x4 CONFIG_MAX_CPUS=2 CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx" -CONFIG_SPL_TEXT_BASE=0xfffd +CONFIG_SPL_TEXT_BASE=0xfffd8000 CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 CONFIG_DEBUG_UART_BASE=0x3f8 CONFIG_DEBUG_UART_CLOCK=1843200 CONFIG_X86_RUN_64BIT=y CONFIG_TARGET_QEMU_X86_64=y CONFIG_DEBUG_UART=y +# CONFIG_HAVE_MICROCODE is not set CONFIG_SMP=y CONFIG_GENERATE_PIRQ_TABLE=y CONFIG_GENERATE_MP_TABLE=y -- 2.41.0.162.gfafddb0af9-goog