Re: [PATCH v2 11/13] Makefile: remove hardcoded device tree source directory
On Thu, 1 Feb 2024 at 08:36, Bryan Brattlof wrote: > > Some boards that choose to utilize the OF_UPSTREAM directory for their > device tree files will need to specify that directory instead of the > traditional arch/$(ARCH)/dts/* path. > > Include the correct path to the board's dtbs depending on if OF_UPSTREAM > is selected or not. > > Signed-off-by: Bryan Brattlof > --- > Makefile | 18 ++ > scripts/Makefile.spl | 17 + > 2 files changed, 27 insertions(+), 8 deletions(-) > Reviewed-by: Sumit Garg -Sumit > diff --git a/Makefile b/Makefile > index 996a43c8624ae..f81d09c892b80 100644 > --- a/Makefile > +++ b/Makefile > @@ -1184,6 +1184,16 @@ dt_binding_check: scripts_dtc > quiet_cmd_copy = COPY$@ >cmd_copy = cp $< $@ > > +ifeq ($(CONFIG_OF_UPSTREAM),y) > +ifeq ($(CONFIG_ARM64),y) > +dt_dir := dts/upstream/src/arm64 > +else > +dt_dir := dts/upstream/src/$(ARCH) > +endif > +else > +dt_dir := arch/$(ARCH)/dts > +endif > + > ifeq ($(CONFIG_MULTI_DTB_FIT),y) > > ifeq ($(CONFIG_MULTI_DTB_FIT_LZO),y) > @@ -1209,7 +1219,7 @@ endif > > MKIMAGEFLAGS_fit-dtb.blob = -f auto -A $(ARCH) -T firmware -C none -O u-boot > \ > -a 0 -e 0 -E \ > - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > -d /dev/null > + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) -d > /dev/null > > MKIMAGEFLAGS_fit-dtb.blob += -B 0x8 > > @@ -1407,9 +1417,9 @@ MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T > firmware -C none -O u-boot \ > -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -p $(CONFIG_FIT_EXTERNAL_OFFSET) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ > - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(DEVICE_TREE))) \ > - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > \ > - $(patsubst %,-b arch/$(ARCH)/dts/%.dtbo,$(subst > ",,$(CONFIG_OF_OVERLAY_LIST))) > + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(DEVICE_TREE))) \ > + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) \ > + $(patsubst %,-b $(dt_dir)/%.dtbo,$(subst > ",,$(CONFIG_OF_OVERLAY_LIST))) > else > MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ > -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 407fc52376a50..d074ba2350065 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -559,9 +559,15 @@ FORCE: > $(obj)/dts/dt-$(SPL_NAME).dtb: dts/dt.dtb > $(Q)$(MAKE) $(build)=$(obj)/dts spl_dtbs > > -PHONY += dts_dir > -dts_dir: > - $(shell [ -d $(obj)/dts ] || mkdir -p $(obj)/dts) > +ifeq ($(CONFIG_OF_UPSTREAM),y) > +ifeq ($(CONFIG_ARM64),y) > +dt_dir := dts/upstream/src/arm64 > +else > +dt_dir := dts/upstream/src/$(ARCH) > +endif > +else > +dt_dir := arch/$(ARCH)/dts > +endif > > # Declare the contents of the .PHONY variable as phony. We keep that > # information in a variable so we can use it in if_changed and friends. > @@ -569,8 +575,11 @@ dts_dir: > > SPL_OF_LIST_TARGETS = $(patsubst %,dts/%.dtb,$(subst > ",,$(CONFIG_SPL_OF_LIST))) > SHRUNK_ARCH_DTB = $(addprefix $(obj)/,$(SPL_OF_LIST_TARGETS)) > +$(dir $(SHRUNK_ARCH_DTB)): > + $(shell [ -d $@ ] || mkdir -p $@) > + > .SECONDEXPANSION: > -$(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, arch/$(ARCH)/dts/%, $$@) > dts_dir > +$(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, $(dt_dir)/%, $$@) $(dir > $(SHRUNK_ARCH_DTB)) > $(call if_changed,fdtgrep) > > targets += $(SPL_OF_LIST_TARGETS) > -- > 2.43.0 >
Re: [PATCH v4] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
On 1/30/2024 12:03 PM, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
>
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
>
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
>
> Signed-off-by: MD Danish Anwar
> ---
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
>
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>
> drivers/remoteproc/Kconfig| 1 +
> drivers/remoteproc/rproc-uclass.c | 85 +++
> include/remoteproc.h | 35 +
> 3 files changed, 121 insertions(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..0fdf1b38ea 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
> # All users should depend on DM
> config REMOTEPROC
> bool
> + select FS_LOADER
> depends on DM
>
> # Please keep the configuration alphabetically sorted.
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index 28b362c887..76db4157f7 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -961,3 +962,87 @@ unsigned long rproc_parse_resource_table(struct udevice
> *dev, struct rproc *cfg)
>
> return 1;
> }
> +
> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + int len;
> + char *p;
> +
> + if (!rproc_dev || !fw_name)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> +
> + len = strcspn(fw_name, "\n");
> + if (!len) {
> + debug("can't provide empty string for firmware name\n");
> + return -EINVAL;
> + }
> +
> + p = strndup(fw_name, len);
> + if (!p)
> + return -ENOMEM;
> +
> + uc_pdata->fw_name = p;
> +
> + return 0;
> +}
> +
> +int rproc_boot(struct udevice *rproc_dev, size_t fw_size)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + struct udevice *fs_loader;
> + void *addr = malloc(fw_size);
> + int core_id, ret = 0;
> + char *firmware;
> + ulong rproc_addr;
> +
> + if (!rproc_dev)
> + return -EINVAL;
> +
> + if (!addr)
> + return -ENOMEM;
> +
addr is not freed.
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + core_id = dev_seq(rproc_dev);
> + firmware = uc_pdata->fw_name;
> +
> + if (!firmware) {
> + debug("No firmware set for rproc core %d\n", core_id);
> + return -EINVAL;
> + }
> +
> + /* Initialize all rproc cores */
> + rproc_init();
> +
> + /* Loading firmware to a given address */
> + ret = get_fs_loader(_loader);
> + if (ret) {
> + debug("could not get fs loader: %d\n", ret);
> + return ret;
> + }
> +
> + ret = request_firmware_into_buf(fs_loader, firmware, addr, fw_size, 0);
> + if (ret < 0) {
> + debug("could not request %s: %d\n", firmware, ret);
> + return ret;
> + }
> +
> + rproc_addr = (ulong)addr;
> +
> + ret = rproc_load(core_id, rproc_addr, ret);
> + if (ret) {
> + debug("failed to load %s to rproc core %d from addr 0x%08lX err
> %d\n",
> + uc_pdata->fw_name, core_id, rproc_addr, ret);
> + return ret;
> + }
> +
> + ret = rproc_start(core_id);
> + if (ret) {
> + debug("failed to start rproc core %d\n", core_id);
> + return ret;
> + }
> +
> + return ret;
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 91a88791a4..e53f85ba51 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -403,6 +403,7 @@ enum rproc_mem_type {
> * @name: Platform-specific way of naming the Remote proc
> * @mem_type: one of 'enum rproc_mem_type'
> * @driver_plat_data: driver specific platform data that may be needed.
> + * @fw_name: firmware name
> *
> * This can be accessed with dev_get_uclass_plat() for any UCLASS_REMOTEPROC
> * device.
> @@ -412,6 +413,7 @@ struct dm_rproc_uclass_pdata {
> const char *name;
> enum rproc_mem_type mem_type;
> void *driver_plat_data;
> + char *fw_name;
> };
>
> /**
> @@ -705,6 +707,35 @@ unsigned long
Re: [PATCH v3 20/36] mach-snapdragon: carve out no-map regions
On Thu, 1 Feb 2024 at 20:20, Caleb Connolly wrote:
>
>
>
> On 01/02/2024 12:07, Sumit Garg wrote:
> > On Tue, 30 Jan 2024 at 19:35, Caleb Connolly
> > wrote:
> >>
> >> On Qualcomm platforms, the TZ may already have certain memory regions
> >> under protection by the time U-Boot starts. There is a rare case on some
> >> platforms where the prefetcher might speculatively access one of these
> >> regions resulting in a board crash (TZ traps and then resets the board).
> >>
> >> We shouldn't be accessing these regions from within U-Boot anyway, so
> >> let's mark them all with PTE_TYPE_FAULT to prevent any speculative
> >> access and correctly trap in EL1 rather than EL3.
> >>
> >> This is quite costly with caches off (takes ~2 seconds on SDM845 vs 35ms
> >> with caches on). So to minimise the impact this is only enabled on
> >> QCS404 for now (where the issue is known to occur).
> >
> > It only took 65ms with caches off on QCS404 as per below print:
> >
> > carveout time: 65ms
> >
> > It's probably due to some missing bits as pointed below to get it
> > working fast on SDM845 too..
>
> Ah I didn't consider that the difference might really just be the 2M vs
> 4K alignment.
>
> [snip]
>
> >> +
> >> +/* Mark all no-map regions as PTE_TYPE_FAULT to prevent speculative
> >> access.
> >> + * On some platforms this is enough to trigger a security violation and
> >> trap
> >> + * to EL3.
> >> + */
> >> +static void carve_out_reserved_memory(void)
> >> +{
> >> + static struct fdt_resource res[N_RESERVED_REGIONS] = { 0 };
> >> + int parent, rmem, count, i = 0;
> >> + phys_addr_t start;
> >> + size_t size;
> >> +
> >> + /* Some reserved nodes must be carved out, as the cache-prefetcher
> >> may otherwise
> >> +* attempt to access them, causing a security exception.
> >> +*/
> >> + parent = fdt_path_offset(gd->fdt_blob, "/reserved-memory");
> >> + if (parent <= 0) {
> >> + log_err("No reserved memory regions found\n");
> >> + return;
> >> + }
> >> + count = fdtdec_get_child_count(gd->fdt_blob, parent);
> >> + if (count > N_RESERVED_REGIONS) {
> >> + log_err("Too many reserved memory regions!\n");
> >> + count = N_RESERVED_REGIONS;
> >> + }
> >> +
> >> + /* Collect the reserved memory regions */
> >> + fdt_for_each_subnode(rmem, gd->fdt_blob, parent) {
> >> + if (!fdt_getprop(gd->fdt_blob, rmem, "no-map", NULL))
> >> + continue;
> >> + if (fdt_getprop(gd->fdt_blob, rmem, "compatible", NULL))
> >> + continue;
> >> + /* Skip regions that don't have a fixed address/size */
> >> + if (fdt_get_resource(gd->fdt_blob, rmem, "reg", 0,
> >> [i++]))
> >> + i--;
> >> + }
> >> +
> >> + /* Sort the reserved memory regions by address */
> >> + count = i;
> >> + qsort(res, count, sizeof(struct fdt_resource), fdt_cmp_res);
> >> +
> >> + /* Now set the right attributes for them. Often a lot of the
> >> regions are tightly packed together
> >> +* so we can optimise the number of calls to
> >> mmu_change_region_attr() by combining adjacent
> >> +* regions.
> >> +*/
> >> + start = ALIGN_DOWN(res[0].start, SZ_2M);
> >> + size = ALIGN(res[0].end, SZ_4K) - start;
> >> + for (i = 1; i < count; i++) {
> >
> > I suppose this loop fails to configure attributes for the last no-map
> > region like uefi_mem region on QCS404.
>
> Right.
> >
> >> + /* We ideally want to 2M align everything for more
> >> efficient pagetables, but we must avoid
> >> +* overwriting reserved memory regions which shouldn't be
> >> mapped as FAULT (like those with
> >> +* compatible properties).
> >> +* If within 2M of the previous region, bump the size to
> >> include this region. Otherwise
> >> +* start a new region.
> >> +*/
> >> + if (start + size < res[i].start - SZ_2M) {
> >> + debug(" 0x%016llx - 0x%016llx FAULT\n",
> >> + start, start + size);
> >> + mmu_change_region_attr(start, size,
> >> PTE_TYPE_FAULT);
> >
> > Here the size won't always be 2M aligned which is the case for SDM845.
> > I would suggest you do:
> >
> > mmu_change_region_attr(start, ALIGN(size,
> > SZ_2M), PTE_TYPE_FAULT);
>
> This isn't an option as I want to avoid unmapping reserved memory
> regions which have a compatible property; on SDM845 for example this
> includes the cmd-db and rmtfs regions. These are not 2M aligned and
> might be directly adjacent to other regions, so doing an align here
> could result in unmapping part of these regions.
The regions with a compatible property and "no-map" should be mapped
by corresponding drivers
Re: [PATCH v3 03/36] mmc: msm_sdhci: use modern clock handling
On Thu, 1 Feb 2024 at 20:04, Caleb Connolly wrote:
>
>
>
> On 01/02/2024 08:19, Sumit Garg wrote:
> > On Tue, 30 Jan 2024 at 19:35, Caleb Connolly
> > wrote:
> >>
> >> Use the clk_* helper functions and the correct property name for clocks.
> >
> > This still doesn't handle fixed clocks like in case of QCS404, upstream DT
> > says:
> >
> > sdcc1: mmc@7804000 {
> > compatible = "qcom,qcs404-sdhci",
> > "qcom,sdhci-msm-v5";
> > ...
> > clocks = < GCC_SDCC1_AHB_CLK>,
> > < GCC_SDCC1_APPS_CLK>,
> > <_board>;
> > clock-names = "iface", "core", "xo";
> > ...
> > };
> >
> > Due to that "xo" fixed clock we get:
> >
> > MMC: clk_set_rate(clk=ffaf7348, rate=1920)
> > Unknown clock id 0
> > clk_set_rate(clk=ffaf7598, rate=1920)
> > Unknown clock id 0
> > clk_set_rate(clk=ffb08868, rate=40)
> > mmc@7804000: 0
>
> Does MMC work? This doesn't look like a probe failure to me.
>
Yeah it's not a breaking change for MMC but rather an annoying one.
MMC works with following DT hack (as per my comments on the other
patch) and defconfig change as follows:
diff --git a/arch/arm/dts/qcs404.dtsi b/arch/arm/dts/qcs404.dtsi
index 2721f32dfb71..5e6705e82837 100644
--- a/arch/arm/dts/qcs404.dtsi
+++ b/arch/arm/dts/qcs404.dtsi
@@ -730,9 +730,7 @@
tlmm: pinctrl@100 {
compatible = "qcom,qcs404-pinctrl";
- reg = <0x0100 0x20>,
- <0x0130 0x20>,
- <0x07b0 0x20>;
+ reg = <0x0130 0x20>;
reg-names = "south", "north", "east";
interrupts = ;
gpio-ranges = < 0 0 120>;
diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index 3c6bdc2071b2..3596bc650b41 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -43,6 +43,8 @@ CONFIG_BUTTON_KEYBOARD=y
CONFIG_BUTTON_QCOM_PMIC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_MSM=y
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_SDHCI_ADMA=y
CONFIG_PHY=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_QCOM_QCS404=y
> But yes this does look odd, somehow qcs404_clk_set_rate() is being
> called with clk->id == 0. The xo_board clock uses a different driver so
> it can't be that...
>
> Could you try and add some more logging around here? I can't see what
> might be causing this.
I tried to dump the call chain as follows. It starts with clk_get_bulk().
clk_get_bulk()
clk_get_by_index()
clk_get_by_index_nodev()
clk_get_by_index_tail()
clk_set_defaults(clock-controller@180)
clk_set_default_rates()
clk_get_by_indexed_prop(dev=ffb05d70, index=0, clk=ffaf7588)
clk_get_by_index_tail()
clk_set_defaults(clock-controller@180)
clk_set_default_rates()
clk_get_by_indexed_prop(dev=ffb05e50, index=0, clk=ffaf7328)
clk_get_by_index_tail()
clk_set_defaults(clock-controller@180)
clk_set_default_rates()
clk_get_by_indexed_prop(dev=ffb05e50, index=0, clk=ffaf7318)
clk_get_by_index_tail()
clk_set_rate(clk=ffaf7318, rate=1920)
Unknown clock id 0
clk_set_rate(clk=ffaf7588, rate=1920)
Unknown clock id 0
-Sumit
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
On Fri, Feb 2, 2024 at 6:03 AM Rob Herring wrote: > > On Wed, Jan 31, 2024 at 8:09 PM Masahiro Yamada wrote: > > > > On Thu, Feb 1, 2024 at 7:03 AM Rob Herring wrote: > > > > > > On Tue, Jan 30, 2024 at 3:16 AM Masahiro Yamada > > > wrote: > > > > > > > > On Fri, Jan 26, 2024 at 1:04 AM Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Wed, 17 Jan 2024 at 06:14, Simon Glass wrote: > > > > > > > > > > > > Hi Masahiro, Tom, > > > > > > > > > > > > On Tue, 9 Jan 2024 at 07:33, Tom Rini wrote: > > > > > > > > > > > > > > On Tue, Jan 09, 2024 at 11:01:42PM +0900, Masahiro Yamada wrote: > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 3, 2024 at 8:47 AM Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Masahiro, > > > > > > > > > > > > > > > > > > On Wed, Dec 13, 2023 at 5:14 AM Will Deacon > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a > > > > > > > > > > > single file > > > > > > > > > > > containing the built kernel and associated devicetree > > > > > > > > > > > files. > > > > > > > > > > > Compression defaults to gzip which gives a good balance > > > > > > > > > > > of size and > > > > > > > > > > > performance. > > > > > > > > > > > > > > > > > > > > > > The files compress from about 86MB to 24MB using this > > > > > > > > > > > approach. > > > > > > > > > > > > > > > > > > > > > > The FIT can be used by bootloaders which support it, such > > > > > > > > > > > as U-Boot > > > > > > > > > > > and Linuxboot. It permits automatic selection of the > > > > > > > > > > > correct > > > > > > > > > > > devicetree, matching the compatible string of the running > > > > > > > > > > > board with > > > > > > > > > > > the closest compatible string in the FIT. There is no > > > > > > > > > > > need for > > > > > > > > > > > filenames or other workarounds. > > > > > > > > > > > > > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. > > > > > > > > > > > Use > > > > > > > > > > > FIT_COMPRESSION to select a different algorithm. > > > > > > > > > > > > > > > > > > > > > > The FIT can be examined using 'dumpimage -l'. > > > > > > > > > > > > > > > > > > > > > > This features requires pylibfdt (use 'pip install > > > > > > > > > > > libfdt'). It also > > > > > > > > > > > requires compression utilities for the algorithm being > > > > > > > > > > > used. Supported > > > > > > > > > > > compression options are the same as the Image.xxx files. > > > > > > > > > > > For now there > > > > > > > > > > > is no way to change the compression other than by editing > > > > > > > > > > > the rule for > > > > > > > > > > > $(obj)/image.fit > > > > > > > > > > > > > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made > > > > > > > > > > > to support > > > > > > > > > > > this here, since it must be built separately from the > > > > > > > > > > > Linux build. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > Changes in v9: > > > > > > > > > > > - Move the compression control into Makefile.lib > > > > > > > > > > > > > > > > > > > > > > Changes in v8: > > > > > > > > > > > - Drop compatible string in FDT node > > > > > > > > > > > - Correct sorting of MAINTAINERS to before ARM64 PORT > > > > > > > > > > > - Turn compress part of the make_fit.py comment in to a > > > > > > > > > > > sentence > > > > > > > > > > > - Add two blank lines before parse_args() and setup_fit() > > > > > > > > > > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var > > > > > > > > > > > - Use '$( > > > > > > > > > > - Add 'mkimage' details Documentation/process/changes.rst > > > > > > > > > > > - Allow changing the compression used > > > > > > > > > > > - Tweak cover letter since there is only one clean-up > > > > > > > > > > > patch > > > > > > > > > > > > > > > > > > > > > > Changes in v7: > > > > > > > > > > > - Add Image as a dependency of image.fit > > > > > > > > > > > - Drop kbuild tag > > > > > > > > > > > - Add dependency on dtbs > > > > > > > > > > > - Drop unnecessary path separator for dtbs > > > > > > > > > > > - Rebase to -next > > > > > > > > > > > > > > > > > > > > > > Changes in v5: > > > > > > > > > > > - Drop patch previously applied > > > > > > > > > > > - Correct compression rule which was broken in v4 > > > > > > > > > > > > > > > > > > > > > > Changes in v4: > > > > > > > > > > > - Use single quotes for UIMAGE_NAME > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > - Drop temporary file image.itk > > > > > > > > > > > - Drop patch 'Use double quotes for image name' > > > > > > > > > > > - Drop double quotes in use of UIMAGE_NAME > > > > > > > > > > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help > > > > > > > >
Re: [PATCH v4] dma: ti: k3-udma: Use ring_idx to pair k3 nav rings
On 2/2/2024 10:31 AM, Ravi Gunasekaran wrote:
>
>
> On 1/30/2024 11:48 AM, MD Danish Anwar wrote:
>> Use ring_idx to pair rings. ring_idx will be same as tx flow_id for all
>> non-negative flow_ids. For negative flow_ids, ring_idx will be tchan->id
>> added with bchan_cnt.
>>
>> Signed-off-by: MD Danish Anwar
>> ---
>> Changes from v3 to v4:
>> *) No functional change. Splitted the patch out of the series as suggested
>>by Nishant.
>>
>> v3: https://lore.kernel.org/all/20240124064930.1787929-2-danishan...@ti.com/
>>
>> drivers/dma/ti/k3-udma.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
>> index 8a62d63dfe..eea9ec9659 100644
>> --- a/drivers/dma/ti/k3-udma.c
>> +++ b/drivers/dma/ti/k3-udma.c
>> @@ -876,13 +876,20 @@ static int udma_alloc_tx_resources(struct udma_chan
>> *uc)
>> {
>> struct k3_nav_ring_cfg ring_cfg;
>> struct udma_dev *ud = uc->ud;
>> -int ret;
>> +struct udma_tchan *tchan;
>> +int ring_idx, ret;
>>
>> ret = udma_get_tchan(uc);
>> if (ret)
>> return ret;
>>
>> -ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, uc->tchan->id, -1,
>> +tchan = uc->tchan;
>> +if (tchan->tflow_id >= 0)
>> +ring_idx = tchan->tflow_id;
>> +else
>> +ring_idx = ud->bchan_cnt + tchan->id;
>> +
>> +ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, ring_idx, -1,
>> >tchan->t_ring,
>> >tchan->tc_ring);
>> if (ret) {
>
> I see this change present in upstream linux kernel as well.
> You could consider providing the link to kernel if such changes are already
> merged there.
Sure Ravi,
Link to upstream kernel code for the same [1].
Upstream Commit: d2abc982333c02f9e1ff1c6b3782174f5b7662d7
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/ti/k3-udma.c?h=v6.8-rc2#n1686
>
> Reviewed-by: Ravi Gunasekaran
--
Thanks and Regards,
Md Danish Anwar
Re: [PATCH v4] dma: ti: k3-udma: Use ring_idx to pair k3 nav rings
On 1/30/2024 11:48 AM, MD Danish Anwar wrote:
> Use ring_idx to pair rings. ring_idx will be same as tx flow_id for all
> non-negative flow_ids. For negative flow_ids, ring_idx will be tchan->id
> added with bchan_cnt.
>
> Signed-off-by: MD Danish Anwar
> ---
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
>
> v3: https://lore.kernel.org/all/20240124064930.1787929-2-danishan...@ti.com/
>
> drivers/dma/ti/k3-udma.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index 8a62d63dfe..eea9ec9659 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c
> @@ -876,13 +876,20 @@ static int udma_alloc_tx_resources(struct udma_chan *uc)
> {
> struct k3_nav_ring_cfg ring_cfg;
> struct udma_dev *ud = uc->ud;
> - int ret;
> + struct udma_tchan *tchan;
> + int ring_idx, ret;
>
> ret = udma_get_tchan(uc);
> if (ret)
> return ret;
>
> - ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, uc->tchan->id, -1,
> + tchan = uc->tchan;
> + if (tchan->tflow_id >= 0)
> + ring_idx = tchan->tflow_id;
> + else
> + ring_idx = ud->bchan_cnt + tchan->id;
> +
> + ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, ring_idx, -1,
> >tchan->t_ring,
> >tchan->tc_ring);
> if (ret) {
I see this change present in upstream linux kernel as well.
You could consider providing the link to kernel if such changes are already
merged there.
Reviewed-by: Ravi Gunasekaran
Re: [PATCH v4] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 1/30/2024 11:56 AM, MD Danish Anwar wrote: > The fs-loader driver reads env storage_interface and uses it to load > firmware file into memory using the medium set by env. Update the driver > to use env fw_storage_interface as this variable is only used to load > firmwares. The env storage_interface will act as fallback so that the > existing implementations do not break. > > Also update the FS Loader documentation accordingly. > > Signed-off-by: MD Danish Anwar > --- > Changes from v3 to v4: > *) No functional change. Splitted the patch out of the series as suggested >by Nishant. > *) Droppped the RFC tag. > > v3: https://lore.kernel.org/all/20240124064930.1787929-3-danishan...@ti.com/ Acked-by: Ravi Gunasekaran
Re: [RFC] rockchip: spl: Support reading FIT from eMMC boot partition
Hello Jonas,
On 2024-02-02 01:11, Jonas Karlman wrote:
Enable support for loading FIT from eMMC boot partition when
SUPPORT_EMMC_BOOT Kconfig option is enabled.
FIT is only loaded from boot partition when the boot partition is set
to
boot0 (1) or boo1 (2) in the extcsd partition config. FIT is read from
sector 1024 (512 KiB) of the configured boot partition.
Following can be used to write U-Boot to boot partition 1 of eMMC:
# Load TPL+SPL from SD-card
=> load mmc 1:1 2000 idbloader.img
=> mmc dev 0
# Access eMMC user partition
=> mmc partconf 0 0 0 0
# Write TPL+SPL to eMMC user partition (512 KiB @ 32 KiB)
=> mmc write 2000 40 400
# Load FIT from SD-card
=> load mmc 1:1 2000 u-boot.itb
=> mmc dev 0
# Access eMMC boot partition 1
=> mmc partconf 0 0 0 1
# Write FIT to eMMC boot partition 1 (2 MiB @ 512 KiB)
=> mmc write 2000 400 1000
# Configure to use boot partition 1
=> mmc partconf 0 0 1 0
# Show partition config
=> mmc partconf 0
Signed-off-by: Jonas Karlman
---
- Is loading FIT from emmc boot partition a feature of intereset to
anyone else?
I find this quite usable. Thus, I'd support this feature to be polished
further and eventually merged.
- I used a @ 512 KiB offset for FIT, should leave enough space for e.g.
TPL/SPL, vendor storage or environment before FIT.
- Is @ 512 KiB offset a good default option? Or would e.g. @ 0 or
@ 32KiB a more apropriate offset?
- This does not add kind of fallback to use the normal @ 8 MiB offset
in
user partition. Is that something that would be needed?
I'd say that the fallback is needed, because we still want to be able
to continue booting the standard way.
---
arch/arm/mach-rockchip/spl.c | 23 +++
configs/generic-rk3568_defconfig | 1 +
configs/generic-rk3588_defconfig | 1 +
3 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-rockchip/spl.c
b/arch/arm/mach-rockchip/spl.c
index c4d3983a6735..2015d9d72dbd 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -68,9 +68,32 @@ u32 spl_boot_device(void)
u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT) && !IS_SD(mmc)) {
+ switch (EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+ case 1:
+ case 2:
+ /* Read FIT from a boot partition */
+ return MMCSD_MODE_EMMCBOOT;
+ }
+ }
+
return MMCSD_MODE_RAW;
}
+unsigned long arch_spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
unsigned long raw_sect)
+{
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT) && !IS_SD(mmc)) {
+ switch (EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+ case 1:
+ case 2:
+ /* Read FIT from sector 1024 (512 KiB) of boot
partition */
+ return 0x400;
+ }
+ }
+
+ return raw_sect;
+}
+
#define TIMER_LOAD_COUNT_L 0x00
#define TIMER_LOAD_COUNT_H 0x04
#define TIMER_CONTROL_REG 0x10
diff --git a/configs/generic-rk3568_defconfig
b/configs/generic-rk3568_defconfig
index 18a62b0033a0..b90ecb643dc7 100644
--- a/configs/generic-rk3568_defconfig
+++ b/configs/generic-rk3568_defconfig
@@ -51,6 +51,7 @@ CONFIG_ROCKCHIP_GPIO=y
CONFIG_MISC=y
# CONFIG_ROCKCHIP_IODOMAIN is not set
CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_HS200_SUPPORT=y
CONFIG_SPL_MMC_HS200_SUPPORT=y
CONFIG_MMC_DW=y
diff --git a/configs/generic-rk3588_defconfig
b/configs/generic-rk3588_defconfig
index 4755b27c1dea..a9329eb1c625 100644
--- a/configs/generic-rk3588_defconfig
+++ b/configs/generic-rk3588_defconfig
@@ -52,6 +52,7 @@ CONFIG_SPL_CLK=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_MISC=y
CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_HS200_SUPPORT=y
CONFIG_SPL_MMC_HS200_SUPPORT=y
CONFIG_MMC_DW=y
Re: [RFC] rockchip: Reset to bootrom download mode on hang
Hello Jonas,
On 2024-02-02 01:12, Jonas Karlman wrote:
Add support to reset to bootrom download mode on hang in U-Boot SPL and
proper. ROCKCHIP_HANG_TO_BROM can be used to enable this feature.
Example when SPL cannot load FIT:
U-Boot SPL 2024.04-rc1 (Feb 01 2024 - 23:01:12 +)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC2
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
entering download mode ...
resetting ...
Procedure to start bootrom download mode:
- U-Boot SPL or proper write 0xEF08A53C to BOOT_MODE_REG and then reset
- Bootrom loads and run boot code (TPL) from e.g. SPI > eMMC > SD-card
- TPL check for 0xEF08A53C in BOOT_MODE_REG very early, i.e. Rockchip
TPL blobs check for this value directly at start
- TPL return to bootrom with a return value != 0
- Bootrom enter download mode
This also fixes an issue where the BOOT_MODE_REG is reset to 0 when
board is reset on RK35xx after TF-A has been loaded. To fix this the
SOC_CON1 reg value is reset prior to issuing a global reset.
The RK356x TF-A blobs will clear SOC_CON1 as part of a PSCI reset,
however the RK3588 TF-A blobs does not seem to clear SOC_CON1.
Signed-off-by: Jonas Karlman
---
- Is reset to bootrom download mode on hang a feature of intereset to
anyone else?
I find this usable, for example during development. Thus, I'd support
this feature to be polished further and eventually merged.
- How can we best handle the issue with BOOT_MODE_REG being reset?
- Should we instead enable SYSRESET_PSCI and relay on TF-A to properly
reset without loosing value in BOOT_MODE_REG? Currently works on
RK356x bl31 blobs but not on the RK3588 bl31 blobs.
---
arch/arm/mach-rockchip/Kconfig | 9 +++
arch/arm/mach-rockchip/Makefile| 9 ---
arch/arm/mach-rockchip/boot_mode.c | 38 ++
configs/generic-rk3568_defconfig | 1 +
configs/generic-rk3588_defconfig | 1 +
5 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig
b/arch/arm/mach-rockchip/Kconfig
index 6ff0aa6911e2..66556d30af27 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -508,6 +508,15 @@ config TPL_ROCKCHIP_EARLYRETURN_TO_BROM
This enables support code in the BOOT0 hook for the TPL stage
to allow multiple entries.
+config ROCKCHIP_HANG_TO_BROM
+ bool "Reset to bootrom download mode on hang"
+ select SHOW_BOOT_PROGRESS
+
+config SPL_ROCKCHIP_HANG_TO_BROM
+ bool "Reset to bootrom download mode on hang in SPL"
+ default y if ROCKCHIP_HANG_TO_BROM
+ select SPL_SHOW_BOOT_PROGRESS
+
config SPL_MMC
default y if !SPL_ROCKCHIP_BACK_TO_BROM
diff --git a/arch/arm/mach-rockchip/Makefile
b/arch/arm/mach-rockchip/Makefile
index 1dc92066bbf3..ab4446bb6b51 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -16,17 +16,16 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
+obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
+obj-$(CONFIG_MISC_INIT_R) += misc.o
+endif
+ifeq ($(CONFIG_TPL_BUILD),)
# Always include boot_mode.o, as we bypass it (i.e. turn it off)
# inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0. This
way,
# we can have the preprocessor correctly recognise both 0x0 and 0
# meaning "turn it off".
obj-y += boot_mode.o
-obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
-obj-$(CONFIG_MISC_INIT_R) += misc.o
-endif
-
-ifeq ($(CONFIG_TPL_BUILD),)
obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
endif
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
index eb8f65ae4e9d..de9ec1414926 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -23,11 +24,31 @@ int setup_boot_mode(void)
#else
-void set_back_to_bootrom_dnl_flag(void)
+static void set_back_to_bootrom_dnl_flag(void)
{
+ /*
+* These SOC_CON1 regs needs to be cleared before a reset or the
+* BOOT_MODE_REG do not retain its value and it is not possible
+* to reset to bootrom download mode once TF-A has been started.
+*
+* TF-A blobs for RK3568 already clear SOC_CON1 for PSCI reset.
+* However, the TF-A blobs for RK3588 does not clear SOC_CON1.
+*/
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3568))
+ writel(0x4, 0xFDC20104);
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3588))
+ writel(0x, 0xFD58A004);
+
writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
}
+static void
Re: [PATCH 01/18] rockchip: rk3588: use mainline pmu-grf compatible
On Tue, Jan 23, 2024 at 10:50 PM Quentin Schulz wrote:
>
> From: Heiko Stuebner
>
> The compatible for the pmugrf in the mainline kernel is dfferent from the
> one currently used in u-boot. Adapt the -u-boot.dtsi and syscon driver
> to use the correct compatible.
Reviewed-by: Weizhao Ouyang
BR,
Weizhao
>
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Quentin Schulz
> ---
> arch/arm/dts/rk3588s-u-boot.dtsi | 2 +-
> arch/arm/mach-rockchip/rk3588/syscon_rk3588.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
> b/arch/arm/dts/rk3588s-u-boot.dtsi
> index c0fd16c4022..9a5ffec926e 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -66,7 +66,7 @@
>
> pmu1_grf: syscon@fd58a000 {
> bootph-all;
> - compatible = "rockchip,rk3588-pmu1-grf", "syscon";
> + compatible = "rockchip,rk3588-pmugrf", "syscon";
> reg = <0x0 0xfd58a000 0x0 0x2000>;
> };
>
> diff --git a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> index e8772d3a382..7b2cf37d9da 100644
> --- a/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> +++ b/arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
> @@ -10,7 +10,7 @@
>
> static const struct udevice_id rk3588_syscon_ids[] = {
> { .compatible = "rockchip,rk3588-sys-grf", .data =
> ROCKCHIP_SYSCON_GRF },
> - { .compatible = "rockchip,rk3588-pmu1-grf", .data =
> ROCKCHIP_SYSCON_PMUGRF },
> + { .compatible = "rockchip,rk3588-pmugrf", .data =
> ROCKCHIP_SYSCON_PMUGRF },
> { .compatible = "rockchip,rk3588-vop-grf", .data =
> ROCKCHIP_SYSCON_VOP_GRF },
> { .compatible = "rockchip,rk3588-vo-grf", .data =
> ROCKCHIP_SYSCON_VO_GRF },
> { .compatible = "rockchip,pcie30-phy-grf", .data =
> ROCKCHIP_SYSCON_PCIE30_PHY_GRF },
>
> --
> 2.43.0
>
Re: [PATCH v2] qemu-arm: round down memory to multiple of 2MB for LPAE
On Thu, Feb 1, 2024, 14:41 Igor Opaniuk wrote:
> QEMU's -m option can take fractional megabyte values,
> and lowest granularity seems to be 0x2000.
> For example, run qemu with amount of memory set to 15k (0x61A9400):
>
> $ qemu-system-arm -machine virt -cpu cortex-a15 -m 15k \
> -bios denx/u-boot.bin -nographic
>
> => fdt addr $fdt_addr
> => fdt print /memory@4000
> memory@4000 {
> reg = <0x 0x4000 0x 0x061aa000>;
> device_type = "memory";
> };
>
> When LPAE is enabled, 1:1 mapping is created using 2 MB blocks.
> In case amount of memory provided to QEMU is not multiple
> of 2 MB, hang occurs during MMU initialization.
>
> How to reproduce:
> qemu-system-arm -machine virt -m 1058 -nographic -bios u-boot.bin - boots
> qemu-system-arm -machine virt -m 1057 -nographic -bios u-boot.bin - hangs
>
> DRAM: 1 GiB
> initcall: 60011df8
> initcall: 60011904
> New Stack Pointer is: 80fffe90
> initcall: 60011a20
> initcall: 60011bcc
> initcall: 60011bd4
> initcall: 600119b4
> Relocation Offset is: 22042000
> Relocating to 82042000, new gd at 81001ed0, sp at 80fffe90
> initcall: 60011b8c
> initcall: 82053ea0
> initcall: 82053ea8
> initcall: 60012040 (relocated to 82054040)
> dram_bank_mmu_setup: bank: 0
> - hang here during mmu init -
>
> This patches rounds down to the nearest multiple of 2MB when
> CONFIG_ARMV7_LPAE=y.
>
> Fixes: 3fa914af82("arm: qemu: implement enable_caches()")
> Signed-off-by: Igor Opaniuk
>
Reviewed-by: Oleksandr Suvorov >
> ---
>
> Changes in v2:
> - Adjust commit message, add more details
>
> board/emulation/qemu-arm/qemu-arm.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> index 942f1fff571..ecfd19f1a7e 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -127,6 +127,18 @@ int dram_init(void)
> if (fdtdec_setup_mem_size_base() != 0)
> return -EINVAL;
>
> + /*
> +* When LPAE is enabled (ARMv7),
> +* 1:1 mapping is created using 2 MB blocks.
> +*
> +* In case amount of memory provided to QEMU
> +* is not multiple of 2 MB, round down the amount
> +* of available memory to avoid hang during MMU
> +* initialization.
> +*/
> + if (CONFIG_IS_ENABLED(ARMV7_LPAE))
> + gd->ram_size -= (gd->ram_size % 0x20);
> +
> return 0;
> }
>
> --
> 2.34.1
>
>
Re: [PATCH v3 1/3] firmware: psci: Fix bind_smccc_features psci check
Hi Igor, On Thu, Feb 1, 2024 at 10:36 PM Igor Opaniuk wrote: > > Hello Weizhao, > > On Wed, Jan 31, 2024 at 3:15 PM Weizhao Ouyang wrote: > > > > According to PSCI specification DEN0022F, PSCI_FEATURES is used to check > > whether the SMCCC is implemented by discovering SMCCC_VERSION. > > > Could you please add more details to your commit message or as a comment > explaining what exact steps should be done for a full discovery sequence of > Arm > Architecture Service functions, so people don't need to search for > that information explicitly? > > For instance: > Step 1: Determine if SMCCC_VERSION is implemented > - Use firmware data, device tree PSCI node, or ACPI FADT PSCI flag, to > determine whether a > PSCI implementation is present. > - Use PSCI_VERSION to learn whether PSCI_FEATURES is provided. PSCI_FEATURES > is > mandatory from version 1.0 of PSCI > Step 2. etc. > > I would just pull that info from the latest SMC Calling Convention version > 1.5, > from 9 Appendix B: Discovery of Arm Architecture Service functions. > > Thank you! > > Signed-off-by: Weizhao Ouyang > > --- > > v3: remove fallback smc call > > v2: check SMCCC_ARCH_FEATURES > > --- > > drivers/firmware/psci.c | 5 - > > include/linux/arm-smccc.h | 6 ++ > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c > > index c6b9efab41..03544d76ed 100644 > > --- a/drivers/firmware/psci.c > > +++ b/drivers/firmware/psci.c > > @@ -135,10 +135,13 @@ static int bind_smccc_features(struct udevice *dev, > > int psci_method) > > PSCI_VERSION_MAJOR(psci_0_2_get_version()) == 0) > > return 0; > > > > - if (request_psci_features(ARM_SMCCC_ARCH_FEATURES) == > > + if (request_psci_features(ARM_SMCCC_VERSION) == > > PSCI_RET_NOT_SUPPORTED) > > return 0; > > > > + if (invoke_psci_fn(ARM_SMCCC_VERSION, 0, 0, 0) < > > ARM_SMCCC_VERSION_1_1) > > + return 0; > > + > IMO, to fully comply with SMC Calling Convention version 1.5 > we should also check for SMCCC_ARCH_WORKAROUND_1: > > From 9 Appendix B: Discovery of Arm Architecture Service functions, > Step 2: Determine if Arm Architecture Service function is implemented > - Use SMCCC_VERSION to learn whether the calling convention complies > to version 1.1 or above. > - Use SMCCC_ARCH_FEATURES to query whether the Arm Architecture > Service function is implemented > on this system <--- we lack of this step Thanks for your review. The 9 Appendix B describes an approach to discovery the maximize ability without causing unsafe behavior on existing platforms. Regarding the second step, it is just using SMCCC_ARCH_WORKAROUND_1 as an example to test SMCCC_ARCH_FEATURES. For the U-Boot case, we can revisit this from two perspectives: 1. SMCCC_ARCH_FEATURES is MANDATORY from SMCCC v1.1. 2. SMCCC_VERSION is OPTIONAL for SMCCC v1.0, so we should consider a safe behavior. 3. U-Boot is using CONFIG_ARM_SMCCC_FEATURES to probe and bind SMCCC service driver if this driver is reported as supported. 4. U-Boot SMCCC service driver can embed its discovery process in is_supported() callback. So now we can choose the following approach in U-Boot: - Use firmware data (check "arm,psci-1.0") to determine whether a PSCI implementation is present. - Use PSCI_VERSION (psci_0_2_get_version() major version >= 0) to learn whether PSCI_FEATURES is provided. - Use PSCI_FEATURES with the SMCCC_VERSION Function Identifier as a parameter to determine that SMCCC_VERSION is implemented. - Use SMCCC_VERSION to learn whether the calling convention complies to version 1.1 or above. - Trying to probe and bind SMCCC service driver. BR, Weizhao > > > if (psci_method == PSCI_METHOD_HVC) > > pdata->invoke_fn = smccc_invoke_hvc; > > else > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h > > index f44e9e8f93..da3d29aabe 100644 > > --- a/include/linux/arm-smccc.h > > +++ b/include/linux/arm-smccc.h > > @@ -55,8 +55,14 @@ > > #define ARM_SMCCC_QUIRK_NONE 0 > > #define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register > > a6 */ > > > > +#define ARM_SMCCC_VERSION 0x8000 > > #define ARM_SMCCC_ARCH_FEATURES0x8001 > > > > +#define ARM_SMCCC_VERSION_1_0 0x1 > > +#define ARM_SMCCC_VERSION_1_1 0x10001 > > +#define ARM_SMCCC_VERSION_1_2 0x10002 > > +#define ARM_SMCCC_VERSION_1_3 0x10003 > > + > > #define ARM_SMCCC_RET_NOT_SUPPORTED((unsigned long)-1) > > > > #ifndef __ASSEMBLY__ > > -- > > 2.39.2 > > > > > -- > Best regards - Freundliche Grüsse - Meilleures salutations > > Igor Opaniuk > Senior Software Engineer, Embedded & Security > E: igor.opan...@foundries.io > W: www.foundries.io
Re: [PATCH v3 1/3] firmware: psci: Fix bind_smccc_features psci check
Hi Abdellatif, On Thu, Feb 1, 2024 at 7:40 PM Abdellatif El Khlifi wrote: > > Hi Weizhao, > > > - if (request_psci_features(ARM_SMCCC_ARCH_FEATURES) == > > + if (request_psci_features(ARM_SMCCC_VERSION) == > > PSCI_RET_NOT_SUPPORTED) > > return 0; > > > > + if (invoke_psci_fn(ARM_SMCCC_VERSION, 0, 0, 0) < > > ARM_SMCCC_VERSION_1_1) > > + return 0; > > It makes sense to me, thanks. > > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h > > index f44e9e8f93..da3d29aabe 100644 > > --- a/include/linux/arm-smccc.h > > +++ b/include/linux/arm-smccc.h > > @@ -55,8 +55,14 @@ > > #define ARM_SMCCC_QUIRK_NONE 0 > > #define ARM_SMCCC_QUIRK_QCOM_A6 1 /* Save/restore register a6 > > */ > > > > +#define ARM_SMCCC_VERSION0x8000 > > #define ARM_SMCCC_ARCH_FEATURES 0x8001 > > > > +#define ARM_SMCCC_VERSION_1_00x1 > > +#define ARM_SMCCC_VERSION_1_10x10001 > > +#define ARM_SMCCC_VERSION_1_20x10002 > > +#define ARM_SMCCC_VERSION_1_30x10003 > > Apart from ARM_SMCCC_VERSION_1_1, are the other ARM_SMCCC_VERSION_1_x defines > needed ? I'm trying to synchronize with linux kernel, it might be a bit odd to add only one version. BR, Weizhao > > Cheers, > Abdellatif
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
Hello Andre,
On 2024-02-02 01:12, Andre Przywara wrote:
On Thu, 1 Feb 2024 18:35:28 + Shantur Rathore
wrote:
On Thu, Feb 1, 2024 at 4:46 PM Andre Przywara
wrote:
> On Thu, 1 Feb 2024 09:39:54 + Shantur Rathore wrote:
> > On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara
wrote:
> > > On Sat, 9 Dec 2023 18:10:56 + Shantur Rathore
wrote:
> > > > Currently when a hub is turned on, all the ports are powered on.
> > > > This works well for hubs which have individual power control.
> > > >
> > > > For the hubs without individual power control this has no effect.
> > > > Mostly in these scenarios the hub port is powered before the USB
> > > > controller is enabled, this can lead to some devices in unexpected
> > > > state.
> > > >
> > > > With this patch, we explicitly reset the port while powering up hub
> > > > This resets the port for hubs without port power control and has
> > > > no effect on hubs with port power control as the port is still off.
> > > >
> > > > Before this patch AMicro AM8180 based NVME to USB adapter won't be
> > > > detected as a USB3.0 Mass Storage device but with this it works as
> > > > expected.
> > > >
> > > > Tested working after this patch:
> > > > 1. AMicro AM8180 based NVME to USB Adapter
> > > > 2. Kingston DataTraveler 3.0
> > > > 3. GenesysLogic USB3.0 Hub
> > > >
> > > > The drives were tested while connected directly and via the hub.
> > >
> > > so this broke USB operation on some Allwinner boards. The ports still
> > > enumerate correctly, but no devices are detected. With mainline
> > > (containing this patch), and a USB stick connected:
> > > starting USB...
> > > Bus usb@520: USB EHCI 1.00
> > > Bus usb@5200400: USB OHCI 1.0
> > > scanning bus usb@520 for devices... 1 USB Device(s) found
> > > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> > >scanning usb for storage devices... 0 Storage Device(s) found
> > >
> > > With this patch here reverted:
> > > starting USB...
> > > Bus usb@520: USB EHCI 1.00
> > > Bus usb@5200400: USB OHCI 1.0
> > > scanning bus usb@520 for devices... 2 USB Device(s) found
> > > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> > >scanning usb for storage devices... 1 Storage Device(s) found
> > >
> > > I have no clue why this happens, there is no discrete hub anywhere in this
> > > setup, so I guess the code runs for the root hub here?
> > > I am attaching a log with DEBUG enabled for common/usb_hub.c, for both
> > > cases.
> > >
> > > Any clues, debug suggestions, or even a fix are warmly welcome.
> > >
> >
> > Which USB disk are you using? Is it a USB 2.0 disk ?
> > Can you try with any other USB disk to confirm?
>
> Yes, this was some USB 2.0 memory stick, on an USB 2.0 port.
> Most sunxi boards only have USB 2.0, but there is one SoC with USB 3.0, I
> will try some combinations later tonight.
That would be awesome.
We need to test
USB 3.0 and 2.0 ports with USB 3.0 and 2.0 drives.
So I had some mixed and apparently inconsistent results:
- On the Pine-H64 (H6 SoC with USB 3.0 + USB 2.0) it worked with
mainline, but only after I applied some pending sunxi USB PHY
regulator patches. This is an unrelated issue, those patches
are needed to enable USB 3.0 support on that board (shared regulator
conflict).
I tested a USB 2.0 and a USB 3.0 drive in both kind of slots, with
and without the patch.
- On the OrangePi Zero 3 (H616 SoC with USB 2.0 only), the USB 3.0
drive would not work with mainline. A USB 2.0 drive was fine.
Applying your patch below fixed that problem, now both drives worked.
Let me interject, please...
Huh, this (mih)behavior with the tested OrangePi Zero 3 is really
strange. As we know, a USB 3.0 drive plugged into a USB 2.0 port
should behave just like a USB 2.0 drive, using the separate set
of pins inside the connector.
If possible, performing some additional testing with another USB
3.0 drive would be quite interesting. Could it be that something
is wrong with the USB 2.0 receptacle on your OrangePi Zero 3,
mechanically or electrically?
- On the OrangePi Zero (H3 with USB 2.0 only), it worked with and
without the patch below, with both the USB 2.0 and USB 3.0 drive.
- On the BananaPi M64 (A64 with USB 2.0 only and an onboard USB 2.0
hub) it also worked in all cases: with and without the patch, USB 2.0
and USB 3.0 drive.
So the good news is: with the patch below it worked in all cases, with
all drives in all slots, on all boards. With current mainline some
drives don't work at least on the board with the H616 SoC.
I cannot really say if that makes sense, and the results above maybe
more per board than per SoC (different VBUS supply), but would
pragmatically tend to use the patch, feel free to add my Tested-by:
when sending:
Tested-by: Andre Przywara
Just one tiny thing:
Once you have tested it, can you please try the patch below
debug("enabling power on all ports\n");
for (i = 0; i <
[PATCH 2/2] mx6sabresd: Convert to watchdog driver model
From: Fabio Estevam
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.
Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi | 9 +
configs/mx6sabresd_defconfig | 3 +++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
index 5c4101b76da2..9e9c4422f00e 100644
--- a/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi
@@ -9,6 +9,11 @@
aliases {
mmc1 =
};
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ };
};
{
@@ -18,3 +23,7 @@
_usdhc3 {
bootph-pre-ram;
};
+
+ {
+ bootph-pre-ram;
+};
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index f19df607e7ae..69685f12eb10 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -103,6 +103,8 @@ CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_MXC_SPI=y
@@ -129,3 +131,4 @@ CONFIG_IMX_HDMI=y
CONFIG_SPLASH_SCREEN=y
CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_BMP_16BPP=y
+CONFIG_IMX_WATCHDOG=y
--
2.34.1
[PATCH 1/2] mx6sabresd: Fix U-Boot corruption after saving the environment
From: Fabio Estevam
U-Boot binary has grown in such a way that it goes beyond the reserved
area for the environment variables.
Running "saveenv" and rebooting the board causes U-Boot to hang because
of this overlap.
Fix this problem by increasing the CONFIG_ENV_OFFSET.
Also, to prevent this same problem to happen in the future, use
CONFIG_BOARD_SIZE_LIMIT, which can detect the overlap in build-time.
CONFIG_BOARD_SIZE_LIMIT is calculated as follows:
CONFIG_BOARD_SIZE_LIMIT = CONFIG_ENV_OFFSET - u-boot-img.dtb offset
CONFIG_BOARD_SIZE_LIMIT = 0xd000 - 69 * 1024
CONFIG_BOARD_SIZE_LIMIT = 781312
Signed-off-by: Fabio Estevam
---
configs/mx6sabresd_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index a90efe4a7786..f19df607e7ae 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -9,7 +9,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_ENV_SIZE=0x2000
-CONFIG_ENV_OFFSET=0xC
+CONFIG_ENV_OFFSET=0xd
CONFIG_MX6QDL=y
CONFIG_TARGET_MX6SABRESD=y
CONFIG_DM_GPIO=y
@@ -24,6 +24,8 @@ CONFIG_PCI=y
CONFIG_FIT=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
+CONFIG_HAS_BOARD_SIZE_LIMIT=y
+CONFIG_BOARD_SIZE_LIMIT=781312
CONFIG_SUPPORT_RAW_INITRD=y
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="run findfdt;mmc dev ${mmcdev};if mmc rescan; then if run
loadbootscript; then run bootscript; else if run loadimage; then run mmcboot;
else run netboot; fi; fi; else run netboot; fi"
--
2.34.1
[PATCH 3/6] arm: mach-k3: Move tispl.bin loading into R5 directory
ATF, OPTEE, DM (tispl.bin) loading is only ever done by the R5 core,
move the code into the R5 directory.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/common.c| 248 +-
arch/arm/mach-k3/r5/common.c | 249 +++
2 files changed, 252 insertions(+), 245 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 5d53efed85b..8db7ca0725e 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -28,27 +28,6 @@
#include
#include
-#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
-enum {
- IMAGE_ID_ATF,
- IMAGE_ID_OPTEE,
- IMAGE_ID_SPL,
- IMAGE_ID_DM_FW,
- IMAGE_AMT,
-};
-
-#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS)
-static const char *image_os_match[IMAGE_AMT] = {
- "arm-trusted-firmware",
- "tee",
- "U-Boot",
- "DM",
-};
-#endif
-
-static struct image_info fit_image_info[IMAGE_AMT];
-#endif
-
struct ti_sci_handle *get_ti_sci_handle(void)
{
struct udevice *dev;
@@ -128,233 +107,12 @@ int early_console_init(void)
}
#endif
-#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
-
-void init_env(void)
-{
-#ifdef CONFIG_SPL_ENV_SUPPORT
- char *part;
-
- env_init();
- env_relocate();
- switch (spl_boot_device()) {
- case BOOT_DEVICE_MMC2:
- part = env_get("bootpart");
- env_set("storage_interface", "mmc");
- env_set("fw_dev_part", part);
- break;
- case BOOT_DEVICE_SPI:
- env_set("storage_interface", "ubi");
- env_set("fw_ubi_mtdpart", "UBI");
- env_set("fw_ubi_volume", "UBI0");
- break;
- default:
- printf("%s from device %u not supported!\n",
- __func__, spl_boot_device());
- return;
- }
-#endif
-}
-
-int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
-{
- struct udevice *fsdev;
- char *name = NULL;
- int size = 0;
-
- if (!IS_ENABLED(CONFIG_FS_LOADER))
- return 0;
-
- *loadaddr = 0;
-#ifdef CONFIG_SPL_ENV_SUPPORT
- switch (spl_boot_device()) {
- case BOOT_DEVICE_MMC2:
- name = env_get(name_fw);
- *loadaddr = env_get_hex(name_loadaddr, *loadaddr);
- break;
- default:
- printf("Loading rproc fw image from device %u not supported!\n",
- spl_boot_device());
- return 0;
- }
-#endif
- if (!*loadaddr)
- return 0;
-
- if (!get_fs_loader()) {
- size = request_firmware_into_buf(fsdev, name, (void *)*loadaddr,
-0, 0);
- }
-
- return size;
-}
-
-void release_resources_for_core_shutdown(void)
-{
- struct ti_sci_handle *ti_sci = get_ti_sci_handle();
- struct ti_sci_dev_ops *dev_ops = _sci->ops.dev_ops;
- struct ti_sci_proc_ops *proc_ops = _sci->ops.proc_ops;
- int ret;
- u32 i;
-
- /* Iterate through list of devices to put (shutdown) */
- for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
- u32 id = put_device_ids[i];
-
- ret = dev_ops->put_device(ti_sci, id);
- if (ret)
- panic("Failed to put device %u (%d)\n", id, ret);
- }
-
- /* Iterate through list of cores to put (shutdown) */
- for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
- u32 id = put_core_ids[i];
-
- /*
-* Queue up the core shutdown request. Note that this call
-* needs to be followed up by an actual invocation of an WFE
-* or WFI CPU instruction.
-*/
- ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
- if (ret)
- panic("Failed sending core %u shutdown message (%d)\n",
- id, ret);
- }
-}
-
-void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
-{
- typedef void __noreturn (*image_entry_noargs_t)(void);
- struct ti_sci_handle *ti_sci = get_ti_sci_handle();
- u32 loadaddr = 0;
- int ret, size = 0, shut_cpu = 0;
-
- /* Release all the exclusive devices held by SPL before starting ATF */
- ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
-
- ret = rproc_init();
- if (ret)
- panic("rproc failed to be initialized (%d)\n", ret);
-
- init_env();
-
- if (!fit_image_info[IMAGE_ID_DM_FW].image_start) {
- size = load_firmware("name_mcur5f0_0fw", "addr_mcur5f0_0load",
-);
- }
-
- /*
-* It is assumed that remoteproc device 1 is the corresponding
-* Cortex-A core which runs ATF. Make sure DT reflects the same.
-*/
- if
[PATCH 2/6] arm: mach-k3: Move disable_linefill_optimization() into R5 directory
The disable_linefill_optimization() function is only ever loaded by the
R5 core, move the code into the R5 directory.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/common.c| 25 -
arch/arm/mach-k3/r5/Makefile | 1 +
arch/arm/mach-k3/r5/common.c | 35 +++
3 files changed, 36 insertions(+), 25 deletions(-)
create mode 100644 arch/arm/mach-k3/r5/common.c
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index f411366778f..5d53efed85b 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -453,31 +453,6 @@ void board_prep_linux(struct bootm_headers *images)
}
#endif
-#ifdef CONFIG_CPU_V7R
-void disable_linefill_optimization(void)
-{
- u32 actlr;
-
- /*
-* On K3 devices there are 2 conditions where R5F can deadlock:
-* 1.When software is performing series of store operations to
-* cacheable write back/write allocate memory region and later
-* on software execute barrier operation (DSB or DMB). R5F may
-* hang at the barrier instruction.
-* 2.When software is performing a mix of load and store operations
-* within a tight loop and store operations are all writing to
-* cacheable write back/write allocates memory regions, R5F may
-* hang at one of the load instruction.
-*
-* To avoid the above two conditions disable linefill optimization
-* inside Cortex R5F.
-*/
- asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
- actlr |= (1 << 13); /* Set DLFO bit */
- asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
-}
-#endif
-
static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
enum k3_firewall_region_type fwl_type)
{
diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile
index b99199d3374..8ad86eb2798 100644
--- a/arch/arm/mach-k3/r5/Makefile
+++ b/arch/arm/mach-k3/r5/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
obj-$(CONFIG_SOC_K3_AM625) += am62x/
obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
+obj-y += common.o
obj-y += lowlevel_init.o
obj-y += r5_mpu.o
diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
new file mode 100644
index 000..ef81f50c6c7
--- /dev/null
+++ b/arch/arm/mach-k3/r5/common.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: R5 Common Architecture initialization
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include
+#include
+
+#include "../common.h"
+
+void disable_linefill_optimization(void)
+{
+ u32 actlr;
+
+ /*
+* On K3 devices there are 2 conditions where R5F can deadlock:
+* 1.When software is performing series of store operations to
+* cacheable write back/write allocate memory region and later
+* on software execute barrier operation (DSB or DMB). R5F may
+* hang at the barrier instruction.
+* 2.When software is performing a mix of load and store operations
+* within a tight loop and store operations are all writing to
+* cacheable write back/write allocates memory regions, R5F may
+* hang at one of the load instruction.
+*
+* To avoid the above two conditions disable linefill optimization
+* inside Cortex R5F.
+*/
+ asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
+ actlr |= (1 << 13); /* Set DLFO bit */
+ asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
+}
--
2.39.2
[PATCH 6/6] arm: mach-k3: Move ARM64 specific code into new arm64 directory
Like we did with R5, move ARM64 code into a specific directory to make
it clear what code is only meant to run on each core type.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Makefile| 3 +--
arch/arm/mach-k3/arm64/Makefile | 6 ++
arch/arm/mach-k3/{ => arm64}/arm64-mmu.c | 0
arch/arm/mach-k3/{ => arm64}/cache.S | 0
4 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-k3/arm64/Makefile
rename arch/arm/mach-k3/{ => arm64}/arm64-mmu.c (100%)
rename arch/arm/mach-k3/{ => arm64}/cache.S (100%)
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 42161376469..55c36161b63 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -3,9 +3,8 @@
# Copyright (C) 2017-2018 Texas Instruments Incorporated - https://www.ti.com/
# Lokesh Vutla
+obj-$(CONFIG_ARM64) += arm64/
obj-$(CONFIG_CPU_V7R) += r5/
-obj-$(CONFIG_ARM64) += arm64-mmu.o
-obj-$(CONFIG_ARM64) += cache.o
obj-$(CONFIG_OF_LIBFDT) += common_fdt.o
ifeq ($(CONFIG_OF_LIBFDT)$(CONFIG_OF_SYSTEM_SETUP),yy)
obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
diff --git a/arch/arm/mach-k3/arm64/Makefile b/arch/arm/mach-k3/arm64/Makefile
new file mode 100644
index 000..f3d322e17f8
--- /dev/null
+++ b/arch/arm/mach-k3/arm64/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+
+obj-y += arm64-mmu.o
+obj-y += cache.o
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
similarity index 100%
rename from arch/arm/mach-k3/arm64-mmu.c
rename to arch/arm/mach-k3/arm64/arm64-mmu.c
diff --git a/arch/arm/mach-k3/cache.S b/arch/arm/mach-k3/arm64/cache.S
similarity index 100%
rename from arch/arm/mach-k3/cache.S
rename to arch/arm/mach-k3/arm64/cache.S
--
2.39.2
[PATCH 5/6] arm: mach-k3: Move firewall removal into R5 directory
Firewalls are only ever removed by the R5 core, move this code into
the R5 directory.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/common.c| 44
arch/arm/mach-k3/r5/common.c | 44
2 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 8db7ca0725e..ed8aec360c9 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -211,50 +211,6 @@ void board_prep_linux(struct bootm_headers *images)
}
#endif
-static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
- enum k3_firewall_region_type fwl_type)
-{
- struct ti_sci_fwl_ops *fwl_ops;
- struct ti_sci_handle *ti_sci;
- struct ti_sci_msg_fwl_region region;
- size_t j;
-
- ti_sci = get_ti_sci_handle();
- fwl_ops = _sci->ops.fwl_ops;
-
- for (j = 0; j < fwl_data.regions; j++) {
- region.fwl_id = fwl_data.fwl_id;
- region.region = j;
- region.n_permission_regs = 3;
-
- fwl_ops->get_fwl_region(ti_sci, );
-
- /* Don't disable the background regions */
- if (region.control != 0 &&
- ((region.control >> K3_FIREWALL_BACKGROUND_BIT) & 1) ==
fwl_type) {
- pr_debug("Attempting to disable firewall %5d (%25s)\n",
-region.fwl_id, fwl_data.name);
- region.control = 0;
-
- if (fwl_ops->set_fwl_region(ti_sci, ))
- pr_err("Could not disable firewall %5d
(%25s)\n",
- region.fwl_id, fwl_data.name);
- }
- }
-}
-
-void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size)
-{
- size_t i;
-
- for (i = 0; i < fwl_data_size; i++) {
- remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
- K3_FIREWALL_REGION_FOREGROUND);
- remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
- K3_FIREWALL_REGION_BACKGROUND);
- }
-}
-
void spl_enable_cache(void)
{
#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index 87d4712efd4..7309573a3fa 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -247,6 +247,50 @@ void disable_linefill_optimization(void)
asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
}
+static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
+ enum k3_firewall_region_type fwl_type)
+{
+ struct ti_sci_fwl_ops *fwl_ops;
+ struct ti_sci_handle *ti_sci;
+ struct ti_sci_msg_fwl_region region;
+ size_t j;
+
+ ti_sci = get_ti_sci_handle();
+ fwl_ops = _sci->ops.fwl_ops;
+
+ for (j = 0; j < fwl_data.regions; j++) {
+ region.fwl_id = fwl_data.fwl_id;
+ region.region = j;
+ region.n_permission_regs = 3;
+
+ fwl_ops->get_fwl_region(ti_sci, );
+
+ /* Don't disable the background regions */
+ if (region.control != 0 &&
+ ((region.control >> K3_FIREWALL_BACKGROUND_BIT) & 1) ==
fwl_type) {
+ pr_debug("Attempting to disable firewall %5d (%25s)\n",
+region.fwl_id, fwl_data.name);
+ region.control = 0;
+
+ if (fwl_ops->set_fwl_region(ti_sci, ))
+ pr_err("Could not disable firewall %5d
(%25s)\n",
+ region.fwl_id, fwl_data.name);
+ }
+ }
+}
+
+void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size)
+{
+ size_t i;
+
+ for (i = 0; i < fwl_data_size; i++) {
+ remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
+ K3_FIREWALL_REGION_FOREGROUND);
+ remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
+ K3_FIREWALL_REGION_BACKGROUND);
+ }
+}
+
#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS)
void board_fit_image_post_process(const void *fit, int node, void **p_image,
size_t *p_size)
--
2.39.2
[PATCH 4/6] arm: mach-k3: am62a7: Disable firewalls only after loading SYSFW
Currently we do this multiple times, instead just do it once after loading
SYSFW in R5 SPL.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am62a7_init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index d72e19936b9..ccbde5bdd85 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -142,6 +142,9 @@ void board_init_f(ulong dummy)
panic("ROM has not loaded TIFS firmware\n");
k3_sysfw_loader(true, NULL, NULL);
+
+ /* Disable ROM configured firewalls right after loading sysfw */
+ remove_fwl_configs(cbass_main_fwls, ARRAY_SIZE(cbass_main_fwls));
#endif
#if defined(CONFIG_CPU_V7R)
@@ -170,9 +173,6 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
- /* Disable ROM configured firewalls right after loading sysfw */
- remove_fwl_configs(cbass_main_fwls, ARRAY_SIZE(cbass_main_fwls));
-
#if defined(CONFIG_K3_AM62A_DDRSS)
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
--
2.39.2
[PATCH 1/6] arm: mach-k3: Move SYS_K3_SPL_ATF definition into R5 Kconfig
Loading ATF is only supported from the R5, move the Kconfig symbol definition to match. Signed-off-by: Andrew Davis --- arch/arm/mach-k3/Kconfig| 7 --- arch/arm/mach-k3/r5/Kconfig | 6 ++ 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 03898424c95..45cf740bb1f 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -114,13 +114,6 @@ config K3_EARLY_CONS_IDX Use this option to set the index of the serial device to be used for the early console during SPL execution. -config SYS_K3_SPL_ATF - bool "Start Cortex-A from SPL" - depends on CPU_V7R - help - Enabling this will try to start Cortex-A (typically with ATF) - after SPL from R5. - config K3_ATF_LOAD_ADDR hex "Load address of ATF image" default 0x7000 diff --git a/arch/arm/mach-k3/r5/Kconfig b/arch/arm/mach-k3/r5/Kconfig index ae79f8ff6cd..317a6c4b67e 100644 --- a/arch/arm/mach-k3/r5/Kconfig +++ b/arch/arm/mach-k3/r5/Kconfig @@ -43,3 +43,9 @@ config K3_SYSFW_IMAGE_SPI_OFFS help Offset of the combined System Firmware and configuration image tree blob to be loaded when booting from a SPI flash memory. + +config SYS_K3_SPL_ATF + bool "Start Cortex-A from SPL" + help + Enabling this will try to start Cortex-A (typically with ATF) + after SPL from R5. -- 2.39.2
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On Thu, 1 Feb 2024 18:35:28 +
Shantur Rathore wrote:
Hi Shantur,
> Hi Andre,
>
> On Thu, Feb 1, 2024 at 4:46 PM Andre Przywara wrote:
> >
> > On Thu, 1 Feb 2024 09:39:54 +
> > Shantur Rathore wrote:
> >
> > Hi Shantur,
> >
> > > On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara
> > > wrote:
> > > >
> > > > On Sat, 9 Dec 2023 18:10:56 +
> > > > Shantur Rathore wrote:
> > > >
> > > > Hi,
> > > >
> > > > > Currently when a hub is turned on, all the ports are powered on.
> > > > > This works well for hubs which have individual power control.
> > > > >
> > > > > For the hubs without individual power control this has no effect.
> > > > > Mostly in these scenarios the hub port is powered before the USB
> > > > > controller is enabled, this can lead to some devices in unexpected
> > > > > state.
> > > > >
> > > > > With this patch, we explicitly reset the port while powering up hub
> > > > > This resets the port for hubs without port power control and has
> > > > > no effect on hubs with port power control as the port is still off.
> > > > >
> > > > > Before this patch AMicro AM8180 based NVME to USB adapter won't be
> > > > > detected as a USB3.0 Mass Storage device but with this it works as
> > > > > expected.
> > > > >
> > > > > Tested working after this patch:
> > > > > 1. AMicro AM8180 based NVME to USB Adapter
> > > > > 2. Kingston DataTraveler 3.0
> > > > > 3. GenesysLogic USB3.0 Hub
> > > > >
> > > > > The drives were tested while connected directly and via the hub.
> > > >
> > > > so this broke USB operation on some Allwinner boards. The ports still
> > > > enumerate correctly, but no devices are detected. With mainline
> > > > (containing this patch), and a USB stick connected:
> > > > starting USB...
> > > > Bus usb@520: USB EHCI 1.00
> > > > Bus usb@5200400: USB OHCI 1.0
> > > > scanning bus usb@520 for devices... 1 USB Device(s) found
> > > > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> > > >scanning usb for storage devices... 0 Storage Device(s) found
> > > >
> > > > With this patch here reverted:
> > > > starting USB...
> > > > Bus usb@520: USB EHCI 1.00
> > > > Bus usb@5200400: USB OHCI 1.0
> > > > scanning bus usb@520 for devices... 2 USB Device(s) found
> > > > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> > > >scanning usb for storage devices... 1 Storage Device(s) found
> > > >
> > > > I have no clue why this happens, there is no discrete hub anywhere in
> > > > this
> > > > setup, so I guess the code runs for the root hub here?
> > > > I am attaching a log with DEBUG enabled for common/usb_hub.c, for both
> > > > cases.
> > > >
> > > > Any clues, debug suggestions, or even a fix are warmly welcome.
> > > >
> > >
> > > Which USB disk are you using? Is it a USB 2.0 disk ?
> > > Can you try with any other USB disk to confirm?
> >
> > Yes, this was some USB 2.0 memory stick, on an USB 2.0 port.
> > Most sunxi boards only have USB 2.0, but there is one SoC with USB 3.0, I
> > will try some combinations later tonight.
> >
> > Thanks,
> > Andre
>
> That would be awesome.
> We need to test
>
> USB 3.0 and 2.0 ports with USB 3.0 and 2.0 drives.
So I had some mixed and apparently inconsistent results:
- On the Pine-H64 (H6 SoC with USB 3.0 + USB 2.0) it worked with
mainline, but only after I applied some pending sunxi USB PHY
regulator patches. This is an unrelated issue, those patches
are needed to enable USB 3.0 support on that board (shared regulator
conflict).
I tested a USB 2.0 and a USB 3.0 drive in both kind of slots, with
and without the patch.
- On the OrangePi Zero 3 (H616 SoC with USB 2.0 only), the USB 3.0
drive would not work with mainline. A USB 2.0 drive was fine.
Applying your patch below fixed that problem, now both drives worked.
- On the OrangePi Zero (H3 with USB 2.0 only), it worked with and
without the patch below, with both the USB 2.0 and USB 3.0 drive.
- On the BananaPi M64 (A64 with USB 2.0 only and an onboard USB 2.0
hub) it also worked in all cases: with and without the patch, USB 2.0
and USB 3.0 drive.
So the good news is: with the patch below it worked in all cases, with
all drives in all slots, on all boards. With current mainline some
drives don't work at least on the board with the H616 SoC.
I cannot really say if that makes sense, and the results above maybe
more per board than per SoC (different VBUS supply), but would
pragmatically tend to use the patch, feel free to add my Tested-by:
when sending:
Tested-by: Andre Przywara
Just one tiny thing:
> Once you have tested it, can you please try the patch below
>
> debug("enabling power on all ports\n");
> for (i = 0; i < dev->maxchild; i++) {
> - usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
> - debug("Reset : port %d returns %lX\n", i + 1, dev->status);
> + if (usb_hub_is_superspeed(hub)) {
this must be:
[RFC] rockchip: Reset to bootrom download mode on hang
Add support to reset to bootrom download mode on hang in U-Boot SPL and
proper. ROCKCHIP_HANG_TO_BROM can be used to enable this feature.
Example when SPL cannot load FIT:
U-Boot SPL 2024.04-rc1 (Feb 01 2024 - 23:01:12 +)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC2
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
entering download mode ...
resetting ...
Procedure to start bootrom download mode:
- U-Boot SPL or proper write 0xEF08A53C to BOOT_MODE_REG and then reset
- Bootrom loads and run boot code (TPL) from e.g. SPI > eMMC > SD-card
- TPL check for 0xEF08A53C in BOOT_MODE_REG very early, i.e. Rockchip
TPL blobs check for this value directly at start
- TPL return to bootrom with a return value != 0
- Bootrom enter download mode
This also fixes an issue where the BOOT_MODE_REG is reset to 0 when
board is reset on RK35xx after TF-A has been loaded. To fix this the
SOC_CON1 reg value is reset prior to issuing a global reset.
The RK356x TF-A blobs will clear SOC_CON1 as part of a PSCI reset,
however the RK3588 TF-A blobs does not seem to clear SOC_CON1.
Signed-off-by: Jonas Karlman
---
- Is reset to bootrom download mode on hang a feature of intereset to
anyone else?
- How can we best handle the issue with BOOT_MODE_REG being reset?
- Should we instead enable SYSRESET_PSCI and relay on TF-A to properly
reset without loosing value in BOOT_MODE_REG? Currently works on
RK356x bl31 blobs but not on the RK3588 bl31 blobs.
---
arch/arm/mach-rockchip/Kconfig | 9 +++
arch/arm/mach-rockchip/Makefile| 9 ---
arch/arm/mach-rockchip/boot_mode.c | 38 ++
configs/generic-rk3568_defconfig | 1 +
configs/generic-rk3588_defconfig | 1 +
5 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 6ff0aa6911e2..66556d30af27 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -508,6 +508,15 @@ config TPL_ROCKCHIP_EARLYRETURN_TO_BROM
This enables support code in the BOOT0 hook for the TPL stage
to allow multiple entries.
+config ROCKCHIP_HANG_TO_BROM
+ bool "Reset to bootrom download mode on hang"
+ select SHOW_BOOT_PROGRESS
+
+config SPL_ROCKCHIP_HANG_TO_BROM
+ bool "Reset to bootrom download mode on hang in SPL"
+ default y if ROCKCHIP_HANG_TO_BROM
+ select SPL_SHOW_BOOT_PROGRESS
+
config SPL_MMC
default y if !SPL_ROCKCHIP_BACK_TO_BROM
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 1dc92066bbf3..ab4446bb6b51 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -16,17 +16,16 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
+obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
+obj-$(CONFIG_MISC_INIT_R) += misc.o
+endif
+ifeq ($(CONFIG_TPL_BUILD),)
# Always include boot_mode.o, as we bypass it (i.e. turn it off)
# inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0. This way,
# we can have the preprocessor correctly recognise both 0x0 and 0
# meaning "turn it off".
obj-y += boot_mode.o
-obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
-obj-$(CONFIG_MISC_INIT_R) += misc.o
-endif
-
-ifeq ($(CONFIG_TPL_BUILD),)
obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
endif
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
index eb8f65ae4e9d..de9ec1414926 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -23,11 +24,31 @@ int setup_boot_mode(void)
#else
-void set_back_to_bootrom_dnl_flag(void)
+static void set_back_to_bootrom_dnl_flag(void)
{
+ /*
+* These SOC_CON1 regs needs to be cleared before a reset or the
+* BOOT_MODE_REG do not retain its value and it is not possible
+* to reset to bootrom download mode once TF-A has been started.
+*
+* TF-A blobs for RK3568 already clear SOC_CON1 for PSCI reset.
+* However, the TF-A blobs for RK3588 does not clear SOC_CON1.
+*/
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3568))
+ writel(0x4, 0xFDC20104);
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3588))
+ writel(0x, 0xFD58A004);
+
writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
}
+static void rockchip_reset_to_dnl_mode(void)
+{
+ puts("entering download mode ...\n");
+ set_back_to_bootrom_dnl_flag();
+ do_reset(NULL, 0, 0, NULL);
+}
+
/*
* detect download
[RFC] rockchip: spl: Support reading FIT from eMMC boot partition
Enable support for loading FIT from eMMC boot partition when
SUPPORT_EMMC_BOOT Kconfig option is enabled.
FIT is only loaded from boot partition when the boot partition is set to
boot0 (1) or boo1 (2) in the extcsd partition config. FIT is read from
sector 1024 (512 KiB) of the configured boot partition.
Following can be used to write U-Boot to boot partition 1 of eMMC:
# Load TPL+SPL from SD-card
=> load mmc 1:1 2000 idbloader.img
=> mmc dev 0
# Access eMMC user partition
=> mmc partconf 0 0 0 0
# Write TPL+SPL to eMMC user partition (512 KiB @ 32 KiB)
=> mmc write 2000 40 400
# Load FIT from SD-card
=> load mmc 1:1 2000 u-boot.itb
=> mmc dev 0
# Access eMMC boot partition 1
=> mmc partconf 0 0 0 1
# Write FIT to eMMC boot partition 1 (2 MiB @ 512 KiB)
=> mmc write 2000 400 1000
# Configure to use boot partition 1
=> mmc partconf 0 0 1 0
# Show partition config
=> mmc partconf 0
Signed-off-by: Jonas Karlman
---
- Is loading FIT from emmc boot partition a feature of intereset to
anyone else?
- I used a @ 512 KiB offset for FIT, should leave enough space for e.g.
TPL/SPL, vendor storage or environment before FIT.
- Is @ 512 KiB offset a good default option? Or would e.g. @ 0 or
@ 32KiB a more apropriate offset?
- This does not add kind of fallback to use the normal @ 8 MiB offset in
user partition. Is that something that would be needed?
---
arch/arm/mach-rockchip/spl.c | 23 +++
configs/generic-rk3568_defconfig | 1 +
configs/generic-rk3588_defconfig | 1 +
3 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index c4d3983a6735..2015d9d72dbd 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -68,9 +68,32 @@ u32 spl_boot_device(void)
u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT) && !IS_SD(mmc)) {
+ switch (EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+ case 1:
+ case 2:
+ /* Read FIT from a boot partition */
+ return MMCSD_MODE_EMMCBOOT;
+ }
+ }
+
return MMCSD_MODE_RAW;
}
+unsigned long arch_spl_mmc_get_uboot_raw_sector(struct mmc *mmc, unsigned long
raw_sect)
+{
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT) && !IS_SD(mmc)) {
+ switch (EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+ case 1:
+ case 2:
+ /* Read FIT from sector 1024 (512 KiB) of boot
partition */
+ return 0x400;
+ }
+ }
+
+ return raw_sect;
+}
+
#define TIMER_LOAD_COUNT_L 0x00
#define TIMER_LOAD_COUNT_H 0x04
#define TIMER_CONTROL_REG 0x10
diff --git a/configs/generic-rk3568_defconfig b/configs/generic-rk3568_defconfig
index 18a62b0033a0..b90ecb643dc7 100644
--- a/configs/generic-rk3568_defconfig
+++ b/configs/generic-rk3568_defconfig
@@ -51,6 +51,7 @@ CONFIG_ROCKCHIP_GPIO=y
CONFIG_MISC=y
# CONFIG_ROCKCHIP_IODOMAIN is not set
CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_HS200_SUPPORT=y
CONFIG_SPL_MMC_HS200_SUPPORT=y
CONFIG_MMC_DW=y
diff --git a/configs/generic-rk3588_defconfig b/configs/generic-rk3588_defconfig
index 4755b27c1dea..a9329eb1c625 100644
--- a/configs/generic-rk3588_defconfig
+++ b/configs/generic-rk3588_defconfig
@@ -52,6 +52,7 @@ CONFIG_SPL_CLK=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_MISC=y
CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_HS200_SUPPORT=y
CONFIG_SPL_MMC_HS200_SUPPORT=y
CONFIG_MMC_DW=y
--
2.43.0
Help Needed: No UART Output in Mainline U-Boot on MT7620A (ZBT WE826-T2)
Dear U-Boot Community, I am working on porting mainline U-Boot to a standard MT7620A wireless router, specifically the ZBT WE826-T2 (https://openwrt.org/toh/zbtlink/we-826). After building and flashing the mainline U-Boot, I'm encountering an issue where there is no output over UART. So far, I've tried the default configurations for both MT7620 RFB and MT7620-MT7530 RFB targets, with the latter being more of an experimental test as my board lacks a gigabit switch. I’m flashing the standard `u-boot.bin` image. I’ve tried disabling the 'skip low-level configuration' in 'make menuconfig,’ but the issue persists. Despite these efforts, the router's behaviour remains unchanged, showing the same LED behaviour (one of the led’s infrequently but regularly flashing) whether the new U-Boot is flashed or the flash chip is entirely erased. In comparing the Device Trees (DTs) for OpenWrt: - https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826.dtsi - https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a.dtsi with those in U-Boot - https://github.com/u-boot/u-boot/blob/master/arch/mips/dts/mediatek%2Cmt7620-rfb.dts - https://github.com/u-boot/u-boot/blob/master/arch/mips/dts/mt7620.dtsi both look similar to all important characteristics. I noticed both use the uartlite for serial. I’m using Ubuntu 20.04 to compile using OpenWrt’s pre-built toolchain. Any insights or guidance on this matter would be greatly appreciated, especially if someone has experience with UART issues on MT7620A-based hardware in mainline U-Boot. Resolving this could pave the way for easier ports to similar devices. Thank you in advance for your support. Rich
[PATCH 1/2] arm: dts: k3-am64: Sync with kernel v6.7-rc1
From: Nishanth Menon
Sync with kernel v6.7-rc1 and sync up the u-boot dts files accordingly.
Signed-off-by: Nishanth Menon
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am64-main.dtsi| 37 ++---
arch/arm/dts/k3-am64-mcu.dtsi | 2 +
arch/arm/dts/k3-am64.dtsi | 2 +
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 110 --
arch/arm/dts/k3-am642-evm.dts | 37 +
arch/arm/dts/k3-am642-r5-evm.dts | 24 --
arch/arm/dts/k3-am642-r5-sk.dts | 12 ---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 98 ---
arch/arm/dts/k3-am642-sk.dts | 29 +++
9 files changed, 94 insertions(+), 257 deletions(-)
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 0df54a74182..0be642bc1b8 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -38,6 +38,7 @@
};
main_conf: syscon@4300 {
+ bootph-all;
compatible = "ti,j721e-system-controller", "syscon",
"simple-mfd";
reg = <0x0 0x4300 0x0 0x2>;
#address-cells = <1>;
@@ -45,6 +46,7 @@
ranges = <0x0 0x0 0x4300 0x2>;
chipid@14 {
+ bootph-all;
compatible = "ti,am654-chipid";
reg = <0x0014 0x4>;
};
@@ -96,7 +98,8 @@
};
dmss: bus@4800 {
- compatible = "simple-mfd";
+ bootph-all;
+ compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
dma-ranges;
@@ -105,6 +108,7 @@
ti,sci-dev-id = <25>;
secure_proxy_main: mailbox@4d00 {
+ bootph-all;
compatible = "ti,am654-secure-proxy";
#mbox-cells = <1>;
reg-names = "target_data", "rt", "scfg";
@@ -188,6 +192,7 @@
};
dmsc: system-controller@44043000 {
+ bootph-all;
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
@@ -197,22 +202,26 @@
reg = <0x00 0x44043000 0x00 0xfe0>;
k3_pds: power-controller {
+ bootph-all;
compatible = "ti,sci-pm-domain";
#power-domain-cells = <2>;
};
k3_clks: clock-controller {
+ bootph-all;
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
k3_reset: reset-controller {
+ bootph-all;
compatible = "ti,sci-reset";
#reset-cells = <2>;
};
};
main_pmx0: pinctrl@f4000 {
+ bootph-all;
compatible = "pinctrl-single";
reg = <0x00 0xf4000 0x00 0x2d0>;
#pinctrl-cells = <1>;
@@ -221,6 +230,7 @@
};
main_timer0: timer@240 {
+ bootph-all;
compatible = "ti,am654-timer";
reg = <0x00 0x240 0x00 0x400>;
interrupts = ;
@@ -365,6 +375,7 @@
};
main_esm: esm@42 {
+ bootph-pre-ram;
compatible = "ti,j721e-esm";
reg = <0x00 0x42 0x00 0x1000>;
ti,esm-pins = <160>, <161>;
@@ -1158,21 +1169,21 @@
};
main_rti0: watchdog@e00 {
- compatible = "ti,j7-rti-wdt";
- reg = <0x00 0xe00 0x00 0x100>;
- clocks = <_clks 125 0>;
- power-domains = <_pds 125 TI_SCI_PD_EXCLUSIVE>;
- assigned-clocks = <_clks 125 0>;
- assigned-clock-parents = <_clks 125 2>;
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0xe00 0x00 0x100>;
+ clocks = <_clks 125 0>;
+ power-domains = <_pds 125 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <_clks 125 0>;
+ assigned-clock-parents = <_clks 125 2>;
};
main_rti1: watchdog@e01 {
- compatible = "ti,j7-rti-wdt";
- reg = <0x00 0xe01 0x00 0x100>;
- clocks = <_clks 126 0>;
- power-domains = <_pds 126 TI_SCI_PD_EXCLUSIVE>;
- assigned-clocks = <_clks 126 0>;
- assigned-clock-parents = <_clks 126 2>;
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0xe01 0x00 0x100>;
+ clocks = <_clks 126 0>;
+ power-domains = <_pds 126 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <_clks 126 0>;
+
[PATCH 2/2] arm: dts: k3-am64: Sync with kernel v6.8-rc1
Sync with kernel v6.8-rc1 and sync up the u-boot dts files accordingly.
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am64-main.dtsi| 22 +-
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 21 +
arch/arm/dts/k3-am642-evm.dts | 12 +---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 20
arch/arm/dts/k3-am642-sk.dts | 10 --
5 files changed, 35 insertions(+), 50 deletions(-)
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 0be642bc1b8..e348114f42e 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -63,7 +63,7 @@
#phy-cells = <1>;
};
- epwm_tbclk: clock-controller@4140 {
+ epwm_tbclk: clock-controller@4130 {
compatible = "ti,am64-epwm-tbclk";
reg = <0x4130 0x4>;
#clock-cells = <1>;
@@ -138,8 +138,13 @@
<0x00 0x4c00 0x00 0x2>,
<0x00 0x4a82 0x00 0x2>,
<0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt";
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>,
+ <0x00 0x4842 0x00 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt",
+ "ring", "tchan", "rchan", "bchan";
msi-parent = <_main_dmss>;
#dma-cells = <3>;
@@ -155,8 +160,13 @@
reg = <0x00 0x485c 0x00 0x100>,
<0x00 0x4a80 0x00 0x2>,
<0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "rflow";
msi-parent = <_main_dmss>;
#dma-cells = <2>;
@@ -623,6 +633,7 @@
ti,otap-del-sel-mmc-hs = <0x0>;
ti,otap-del-sel-ddr52 = <0x6>;
ti,otap-del-sel-hs200 = <0x7>;
+ status = "disabled";
};
sdhci1: mmc@fa0 {
@@ -641,6 +652,7 @@
ti,otap-del-sel-sdr104 = <0x6>;
ti,otap-del-sel-ddr50 = <0x9>;
ti,clkbuf-sel = <0x7>;
+ status = "disabled";
};
cpsw3g: ethernet@800 {
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index a052941e235..c98adc65e89 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -43,29 +43,10 @@
};
_bcdma {
- reg = <0x00 0x485c0100 0x00 0x100>,
- <0x00 0x4c00 0x00 0x2>,
- <0x00 0x4a82 0x00 0x2>,
- <0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>,
- <0x00 0x4860 0x00 0x8000>,
- <0x00 0x484a4000 0x00 0x2000>,
- <0x00 0x484c2000 0x00 0x2000>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
- "cfg", "tchan", "rchan";
+ bootph-all;
};
_pktdma {
- reg = <0x00 0x485c 0x00 0x100>,
- <0x00 0x4a80 0x00 0x2>,
- <0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>,
- <0x00 0x485e 0x00 0x2>,
- <0x00 0x484a 0x00 0x4000>,
- <0x00 0x484c 0x00 0x2000>,
- <0x00 0x4843 0x00 0x4000>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt", "cfg",
- "tchan", "rchan", "rflow";
bootph-all;
};
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 4dba1894101..8c5651d2cf5 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -468,11 +468,15 @@
bootph-all;
};
-/* mcu_gpio0 is reserved for mcu firmware usage */
+/* mcu_gpio0 and mcu_gpio_intr are reserved for mcu firmware usage */
_gpio0 {
status = "reserved";
};
+_gpio_intr {
+ status =
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
On Wed, Jan 31, 2024 at 8:09 PM Masahiro Yamada wrote: > > On Thu, Feb 1, 2024 at 7:03 AM Rob Herring wrote: > > > > On Tue, Jan 30, 2024 at 3:16 AM Masahiro Yamada > > wrote: > > > > > > On Fri, Jan 26, 2024 at 1:04 AM Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Wed, 17 Jan 2024 at 06:14, Simon Glass wrote: > > > > > > > > > > Hi Masahiro, Tom, > > > > > > > > > > On Tue, 9 Jan 2024 at 07:33, Tom Rini wrote: > > > > > > > > > > > > On Tue, Jan 09, 2024 at 11:01:42PM +0900, Masahiro Yamada wrote: > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 3, 2024 at 8:47 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Masahiro, > > > > > > > > > > > > > > > > On Wed, Dec 13, 2023 at 5:14 AM Will Deacon > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a > > > > > > > > > > single file > > > > > > > > > > containing the built kernel and associated devicetree files. > > > > > > > > > > Compression defaults to gzip which gives a good balance of > > > > > > > > > > size and > > > > > > > > > > performance. > > > > > > > > > > > > > > > > > > > > The files compress from about 86MB to 24MB using this > > > > > > > > > > approach. > > > > > > > > > > > > > > > > > > > > The FIT can be used by bootloaders which support it, such > > > > > > > > > > as U-Boot > > > > > > > > > > and Linuxboot. It permits automatic selection of the correct > > > > > > > > > > devicetree, matching the compatible string of the running > > > > > > > > > > board with > > > > > > > > > > the closest compatible string in the FIT. There is no need > > > > > > > > > > for > > > > > > > > > > filenames or other workarounds. > > > > > > > > > > > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use > > > > > > > > > > FIT_COMPRESSION to select a different algorithm. > > > > > > > > > > > > > > > > > > > > The FIT can be examined using 'dumpimage -l'. > > > > > > > > > > > > > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). > > > > > > > > > > It also > > > > > > > > > > requires compression utilities for the algorithm being > > > > > > > > > > used. Supported > > > > > > > > > > compression options are the same as the Image.xxx files. > > > > > > > > > > For now there > > > > > > > > > > is no way to change the compression other than by editing > > > > > > > > > > the rule for > > > > > > > > > > $(obj)/image.fit > > > > > > > > > > > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made > > > > > > > > > > to support > > > > > > > > > > this here, since it must be built separately from the Linux > > > > > > > > > > build. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > Changes in v9: > > > > > > > > > > - Move the compression control into Makefile.lib > > > > > > > > > > > > > > > > > > > > Changes in v8: > > > > > > > > > > - Drop compatible string in FDT node > > > > > > > > > > - Correct sorting of MAINTAINERS to before ARM64 PORT > > > > > > > > > > - Turn compress part of the make_fit.py comment in to a > > > > > > > > > > sentence > > > > > > > > > > - Add two blank lines before parse_args() and setup_fit() > > > > > > > > > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var > > > > > > > > > > - Use '$( > > > > > > > > > - Add 'mkimage' details Documentation/process/changes.rst > > > > > > > > > > - Allow changing the compression used > > > > > > > > > > - Tweak cover letter since there is only one clean-up patch > > > > > > > > > > > > > > > > > > > > Changes in v7: > > > > > > > > > > - Add Image as a dependency of image.fit > > > > > > > > > > - Drop kbuild tag > > > > > > > > > > - Add dependency on dtbs > > > > > > > > > > - Drop unnecessary path separator for dtbs > > > > > > > > > > - Rebase to -next > > > > > > > > > > > > > > > > > > > > Changes in v5: > > > > > > > > > > - Drop patch previously applied > > > > > > > > > > - Correct compression rule which was broken in v4 > > > > > > > > > > > > > > > > > > > > Changes in v4: > > > > > > > > > > - Use single quotes for UIMAGE_NAME > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > - Drop temporary file image.itk > > > > > > > > > > - Drop patch 'Use double quotes for image name' > > > > > > > > > > - Drop double quotes in use of UIMAGE_NAME > > > > > > > > > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help > > > > > > > > > > - Avoid hard-coding "arm64" for the DT architecture > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > - Drop patch previously applied > > > > > > > > > > - Add .gitignore file > > > > > > > > > > - Move fit rule to Makefile.lib using an intermediate file > > > > > > > > > > - Drop dependency on CONFIG_EFI_ZBOOT > > > > > > >
[PATCH v2 1/1] net: ti: am65-cpsw-nuss: Remove incorrect RGMII_ID bit functionality
The CPSW implementations on the AM6x platforms do not support the
selectable RGMII TX clk delay functionality via the RGMII_ID_MODE bit as
the earlier platforms did. While it is possible to write the bit,
according to various TI AM6x datasheets, reference manuals, hardware
design guides and TI forum posts from TI, this bit is "not timed, tested
or characterized. RGMII_ID is enabled by default."
The driver implementation today however, will incorrectly set this bit
whenever the interface mode is in RGMII_ID or RGMII_TXID. Since
disabling the delay (bit=1) is not supported by TI, this bit should
always be written as 0.
See:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1211306/am625-enet1_ctrl_rgmii_id-_mode
https://www.ti.com/lit/pdf/spruiv7 (Rev. B Figure 14-1717)
https://www.ti.com/lit/gpn/am625 (Rev. B Figure 7-31 Note A)
https://www.ti.com/lit/an/sprad05b/sprad05b.pdf (Rev. B Section 7.4)
Signed-off-by: Ken Sloat
---
Notes:
Changes in v2:
-Explicitly clear RGMII_ID bit in all cases
-Clarify commit message based on items in v1 review
drivers/net/ti/am65-cpsw-nuss.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 6da018c0f9..0836da1583 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -250,13 +250,13 @@ out:
#define AM65_GMII_SEL_MODE_SGMII 3
#define AM65_GMII_SEL_RGMII_IDMODE BIT(4)
+#define AM6X_GMII_SEL_MODE_SEL_MASK GENMASK(2, 0)
static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
phy_interface_t phy_mode)
{
struct udevice *dev = priv->dev;
u32 offset, reg, phandle;
- bool rgmii_id = false;
fdt_addr_t gmii_sel;
u32 mode = 0;
ofnode node;
@@ -296,7 +296,6 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM65_GMII_SEL_MODE_RGMII;
- rgmii_id = true;
break;
case PHY_INTERFACE_MODE_SGMII:
@@ -313,15 +312,16 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
break;
};
- if (rgmii_id)
- mode |= AM65_GMII_SEL_RGMII_IDMODE;
+ /* RGMII_ID_MODE = 1 is not supported */
+ reg &= ~AM65_GMII_SEL_RGMII_IDMODE;
+ reg &= ~AM6X_GMII_SEL_MODE_SEL_MASK;
+ reg |= mode;
- reg = mode;
dev_dbg(dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
phy_mode, reg);
writel(reg, gmii_sel);
- reg = readl(gmii_sel);
+ reg = AM6X_GMII_SEL_MODE_SEL_MASK & readl(gmii_sel);
if (reg != mode) {
dev_err(dev,
"gmii_sel PHY mode NOT SET!: requested: %08x, gmii_sel:
%08x\n",
--
2.34.1
Re: [PATCH 1/3] rockchip: rk35xx: Remove use of eMMC DDR52 mode
Hi Quentin, On 2024-02-01 13:40, Quentin Schulz wrote: > Hi Jonas, > > On 2/1/24 11:51, Jonas Karlman wrote: >> Hi Quentin, >> >> On 2024-02-01 11:18, Quentin Schulz wrote: >>> Hi Jonas, >>> >>> On 1/27/24 12:15, Jonas Karlman wrote: Hi Eugen, On 2024-01-27 04:48, Eugen Hristev wrote: > Hi Jonas, > > > On 1/27/24 01:26, Jonas Karlman wrote: >> Writing to eMMC using DDR52 mode does not work reliably or at all on >> RK356x and RK3588 boards. >> > > > This is related to the old issue I encountered last year with mmc write? Yes, I think it is. I did some testing on RK3566/RK3568/RK3588S/RK3588 boards with different eMMC modules with following result: Read seem to work with all enabled modes: RK3566: MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz) and HS200 (200MHz) RK3568/RK3588S/RK3588: all above + HS400 (200MHz) and HS400ES (200MHz) However, write had issues with some of the modes: MMC DDR52 (52MHz): all RK35xx HS400/HS400ES: only on RK3568 after changing hs400_txclk_tapnum to 8 HS200 seem to be the most stable write speed that worked on all SoCs. So, dropping MMC DDR52 (52MHz) and enable use of HS200 (200MHz) seem to be the best option to get speedy and working read and write eMMC. >>> >>> 1) we have this enabled on RK3588 Jaguar in upstream Linux... I may have >>> improperly tested it then, would you mind sharing how you tested this >>> mode on RK3588 so I can reproduce this and fix it on our product if >>> we're impacted? I assume because we have HS200/HS400/HS400-ES enabled, >>> DDR52 would never be used? (our eMMC is soldered and support the former >>> modes). >> >> My main mode of testing eMMC in U-Boot has been to enable following >> Kconfig options, >> >> CONFIG_MMC_HS200_SUPPORT=y >> CONFIG_MMC_HS400_SUPPORT=y >> CONFIG_MMC_HS400_ES_SUPPORT=y >> CONFIG_MMC_SPEED_MODE_SET=y >> >> and from U-Boot cli run following, >> >> => mmc rescan && mmc info && mmc read 1000 2000 1 >> => mmc rescan && mmc info && mmc write 2000 4000 1 >> >> for each of the modes below. >> >>0 = MMC legacy >>1 = MMC High Speed (26MHz) >>3 = MMC High Speed (52MHz) >>4 = MMC DDR52 (52MHz) >>10 = HS200 (200MHz) >>11 = HS400 (200MHz) >>12 = HS400ES (200MHz) >> >> on different boards and different eMMC modules. >> >> Using some modes the read or write return ERROR instead of OK. When >> ERROR was reported a rescan or board reset was needed to test next mode. >> >> Please also note that I have only tested in U-Boot, not in linux. >> > > Thanks for the tips on how to test these. > > I have run the following commands on an RK3588 Jaguar (master branch + > your v6.8-rc1 DTS sync patch series + Jaguar patch series): > > => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i > in 0 1 3 4 10 11 12; do mmc rescan $i && mmc read 1000 2000 10; > if test $? -ne 0; then echo $i FAILED; fi; done; done > > Which is 20 iterations of an mmc read at each of the 7 supported modes. > The result is: > 1 fail in HS200, 2 fails in HS400, the rest passes just fine. I am wondering if your HS200 fails could be because MMC DDR52 (52MHz) was being tested prior to the HS200 mode. What happens if you exclude the mmc-ddr-1_8v prop and mode 4 in your test loops? I did some quick re-test on a ROCK 5A (rk3588s) and ROCK 5B (rk3588) with DDR52 removed and could only see very few read fails with HS400. > > => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i > in 0 1 3 4 10 11 12; do mmc rescan $i && mmc write 2000 4000 10; > if test $? -ne 0; then echo $i FAILED; fi; done; done > > Which is 20 iterations of an mmc write at each of the 7 supported modes. > The result is: > 20 fails in DDR52, 2 fails in HS200, the rest passes just fine. > > So it seems DDR52, HS200 and HS400 aren't stable on my board, but > HS400ES somehow is (which is enabled in our defconfig). Please re-test with DDR52 mode skipped and see if you get any other result for HS200 mode. And you are correct, HR400ES seem to also be working fine on my RK3588 boards. I can see now that on my old testing commit [1] I only mention and drop the hs400 mode and not the hs400es mode for rk3588. Could also be the change to emmc_data_strobe pinctrl that got synced from linux v6.7 that help improve HR400ES mode results. >From a very quick re-test on two boards with two different emmc modules I could only see a few "Select HS400 failed -70" lines being reported when testing read and/or write using your test loops (with a few modes skipped and smaller amount of data to read/write). Remaining modes seem to be working okay. [1] https://github.com/Kwiboo/u-boot-rockchip/commit/cb1521aea8dee730bddcc5772afa28aa71fc69f9 [2] https://lore.kernel.org/all/20231205202900.4617-2-cfswo...@gmail.com/ Regards, Jonas >
Re: [PATCH] lib: sparse: Fix error checking for write_sparse_chunk_raw
On Thu, Feb 1, 2024 at 7:19 PM Sean Anderson wrote:
>
> The return value of write_sparse_chunk_raw is unsigned, so the existing
> check has no effect. Use IS_ERR_VALUE to detect error instead, which is
> what write_sparse_chunk_raw does itself.
>
> Fixes: 62649165cb0 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
> Reported-by: Dan Carpenter
> Link:
> https://lore.kernel.org/u-boot/1b323ec3-59b0-490b-a2f0-fd961dafcf49@moroto.mountain/
> Signed-off-by: Sean Anderson
> ---
>
> lib/image-sparse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/image-sparse.c b/lib/image-sparse.c
> index f8289064692..09225692e9b 100644
> --- a/lib/image-sparse.c
> +++ b/lib/image-sparse.c
> @@ -211,7 +211,7 @@ int write_sparse_image(struct sparse_storage *info,
>
> blks = write_sparse_chunk_raw(info, blk, blkcnt,
> data, response);
> - if (blks < 0)
> + if (IS_ERR_VALUE(blks))
> return -1;
>
> blk += blks;
> --
> 2.35.1.1320.gc452695387.dirty
>
Reviewed-by: Michael Trimarchi
Michael
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
Hi Andre,
On Thu, Feb 1, 2024 at 4:46 PM Andre Przywara wrote:
>
> On Thu, 1 Feb 2024 09:39:54 +
> Shantur Rathore wrote:
>
> Hi Shantur,
>
> > On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara
> > wrote:
> > >
> > > On Sat, 9 Dec 2023 18:10:56 +
> > > Shantur Rathore wrote:
> > >
> > > Hi,
> > >
> > > > Currently when a hub is turned on, all the ports are powered on.
> > > > This works well for hubs which have individual power control.
> > > >
> > > > For the hubs without individual power control this has no effect.
> > > > Mostly in these scenarios the hub port is powered before the USB
> > > > controller is enabled, this can lead to some devices in unexpected
> > > > state.
> > > >
> > > > With this patch, we explicitly reset the port while powering up hub
> > > > This resets the port for hubs without port power control and has
> > > > no effect on hubs with port power control as the port is still off.
> > > >
> > > > Before this patch AMicro AM8180 based NVME to USB adapter won't be
> > > > detected as a USB3.0 Mass Storage device but with this it works as
> > > > expected.
> > > >
> > > > Tested working after this patch:
> > > > 1. AMicro AM8180 based NVME to USB Adapter
> > > > 2. Kingston DataTraveler 3.0
> > > > 3. GenesysLogic USB3.0 Hub
> > > >
> > > > The drives were tested while connected directly and via the hub.
> > >
> > > so this broke USB operation on some Allwinner boards. The ports still
> > > enumerate correctly, but no devices are detected. With mainline
> > > (containing this patch), and a USB stick connected:
> > > starting USB...
> > > Bus usb@520: USB EHCI 1.00
> > > Bus usb@5200400: USB OHCI 1.0
> > > scanning bus usb@520 for devices... 1 USB Device(s) found
> > > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> > >scanning usb for storage devices... 0 Storage Device(s) found
> > >
> > > With this patch here reverted:
> > > starting USB...
> > > Bus usb@520: USB EHCI 1.00
> > > Bus usb@5200400: USB OHCI 1.0
> > > scanning bus usb@520 for devices... 2 USB Device(s) found
> > > scanning bus usb@5200400 for devices... 1 USB Device(s) found
> > >scanning usb for storage devices... 1 Storage Device(s) found
> > >
> > > I have no clue why this happens, there is no discrete hub anywhere in this
> > > setup, so I guess the code runs for the root hub here?
> > > I am attaching a log with DEBUG enabled for common/usb_hub.c, for both
> > > cases.
> > >
> > > Any clues, debug suggestions, or even a fix are warmly welcome.
> > >
> >
> > Which USB disk are you using? Is it a USB 2.0 disk ?
> > Can you try with any other USB disk to confirm?
>
> Yes, this was some USB 2.0 memory stick, on an USB 2.0 port.
> Most sunxi boards only have USB 2.0, but there is one SoC with USB 3.0, I
> will try some combinations later tonight.
>
> Thanks,
> Andre
That would be awesome.
We need to test
USB 3.0 and 2.0 ports with USB 3.0 and 2.0 drives.
Once you have tested it, can you please try the patch below
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1, dev->status);
+ if (usb_hub_is_superspeed(hub)) {
+ usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
+ debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ }
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug("PowerOn : port %d returns %lX\n", i + 1, dev->status);
}
Thanks
[PATCH] lib: sparse: Fix error checking for write_sparse_chunk_raw
The return value of write_sparse_chunk_raw is unsigned, so the existing
check has no effect. Use IS_ERR_VALUE to detect error instead, which is
what write_sparse_chunk_raw does itself.
Fixes: 62649165cb0 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
Reported-by: Dan Carpenter
Link:
https://lore.kernel.org/u-boot/1b323ec3-59b0-490b-a2f0-fd961dafcf49@moroto.mountain/
Signed-off-by: Sean Anderson
---
lib/image-sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/image-sparse.c b/lib/image-sparse.c
index f8289064692..09225692e9b 100644
--- a/lib/image-sparse.c
+++ b/lib/image-sparse.c
@@ -211,7 +211,7 @@ int write_sparse_image(struct sparse_storage *info,
blks = write_sparse_chunk_raw(info, blk, blkcnt,
data, response);
- if (blks < 0)
+ if (IS_ERR_VALUE(blks))
return -1;
blk += blks;
--
2.35.1.1320.gc452695387.dirty
Re: [PATCH] sunxi: dram: h6: fix the unreliability related to the DDR3 sequence
On Mon, 22 Jan 2024 22:15:30 +0100
patrick9...@free.fr wrote:
Hi Patrick,
> From: Patrick Lerda
>
> Indeed, the DDR3 has a non-zero probability to not be properly
> initialized. This could be the PLL that is not locked or anything else.
> When this happens and the code tests the correct board configuration,
> the proper board configuration is not set. The board could end with
> half the expected memory size, or u-boot could stall.
>
> This change adds a loop to execute the DDR3 sequence again until the
> stable state is reached.
>
> My H6 TX6 board was prone to this issue. Once fixed with this change,
> the same board can now handle 1+ consecutive reboots properly.
That's certainly an interesting approach, though I feel like it papers
over something. So for instance if the PLL is not locked, we should rather
fix that than going the Windows way (retry, reboot, reinstall) ;-)
But indeed there are some reports about instability of the DRAM init,
reporting twice the size being a common issue.
For a start, can you try to apply this series?
https://patchwork.ozlabs.org/project/uboot/list/?series=378679
Also there is this patch:
https://lore.kernel.org/u-boot/20231001161336.31140-2-viran...@gmail.com/
And while I am still a bit sceptical about this solution, this looks
better than just retrying to me.
I would be grateful if you could test these patches and report back.
Cheers,
Andre
> Fixes: ec9cdaaa13d ("sunxi: dram: h6: Improve DDR3 config detection")
> Signed-off-by: Patrick Lerda
> ---
> arch/arm/mach-sunxi/dram_sun50i_h6.c | 207 ++-
> 1 file changed, 111 insertions(+), 96 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> index 62bc2a0231..462adb1c9e 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -420,116 +420,131 @@ static bool mctl_channel_init(struct dram_para *para)
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> struct sunxi_mctl_phy_reg * const mctl_phy =
> (struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
> - int i;
> + int i, j = 0;
> u32 val;
>
> - setbits_le32(_ctl->dfiupd[0], BIT(31) | BIT(30));
> - setbits_le32(_ctl->zqctl[0], BIT(31) | BIT(30));
> - writel(0x2f05, _ctl->sched[0]);
> - setbits_le32(_ctl->rfshctl3, BIT(0));
> - setbits_le32(_ctl->dfimisc, BIT(0));
> - setbits_le32(_ctl->unk_0x00c, BIT(8));
> - clrsetbits_le32(_phy->pgcr[1], 0x180, 0xc0);
> - /* TODO: non-LPDDR3 types */
> - clrsetbits_le32(_phy->pgcr[2], GENMASK(17, 0), ns_to_t(7800));
> - clrbits_le32(_phy->pgcr[6], BIT(0));
> - clrsetbits_le32(_phy->dxccr, 0xee0, 0x220);
> - /* TODO: VT compensation */
> - clrsetbits_le32(_phy->dsgcr, BIT(0), 0x440060);
> - clrbits_le32(_phy->vtcr[1], BIT(1));
> -
> - for (i = 0; i < 4; i++)
> - clrsetbits_le32(_phy->dx[i].gcr[0], 0xe00, 0x800);
> - for (i = 0; i < 4; i++)
> - clrsetbits_le32(_phy->dx[i].gcr[2], 0x, 0x);
> - for (i = 0; i < 4; i++)
> - clrsetbits_le32(_phy->dx[i].gcr[3], 0x3030, 0x1010);
> -
> - udelay(100);
> + do {
> + setbits_le32(_ctl->dfiupd[0], BIT(31) | BIT(30));
> + setbits_le32(_ctl->zqctl[0], BIT(31) | BIT(30));
> + writel(0x2f05, _ctl->sched[0]);
> + setbits_le32(_ctl->rfshctl3, BIT(0));
> + setbits_le32(_ctl->dfimisc, BIT(0));
> + setbits_le32(_ctl->unk_0x00c, BIT(8));
> + clrsetbits_le32(_phy->pgcr[1], 0x180, 0xc0);
> + /* TODO: non-LPDDR3 types */
> + clrsetbits_le32(_phy->pgcr[2], GENMASK(17, 0),
> + ns_to_t(7800));
> + clrbits_le32(_phy->pgcr[6], BIT(0));
> + clrsetbits_le32(_phy->dxccr, 0xee0, 0x220);
> + /* TODO: VT compensation */
> + clrsetbits_le32(_phy->dsgcr, BIT(0), 0x440060);
> + clrbits_le32(_phy->vtcr[1], BIT(1));
>
> - if (para->ranks == 2)
> - setbits_le32(_phy->dtcr[1], 0x3);
> - else
> - clrsetbits_le32(_phy->dtcr[1], 0x3, 0x1);
> + for (i = 0; i < 4; i++)
> + clrsetbits_le32(_phy->dx[i].gcr[0], 0xe00, 0x800);
> + for (i = 0; i < 4; i++)
> + clrsetbits_le32(_phy->dx[i].gcr[2], 0x,
> + 0x);
> + for (i = 0; i < 4; i++)
> + clrsetbits_le32(_phy->dx[i].gcr[3], 0x3030,
> + 0x1010);
>
> - if (sunxi_dram_is_lpddr(para->type))
> - clrbits_le32(_phy->dtcr[1], BIT(1));
> - if (para->ranks == 2) {
> - writel(0x00010001, _phy->rankidr);
> - writel(0x2, _phy->odtcr);
> - } else {
> - writel(0x0, _phy->rankidr);
> -
Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
Hello Quentin, On 2024-02-01 18:46, Quentin Schulz wrote: On 2/1/24 05:02, Dragan Simic wrote: On 2024-02-01 03:48, Kever Yang wrote: On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Compared to the original misc_init_r from Rockchip mach code, setup_iodomain() is added and rockchip_setup_macaddr() is not called. It is assumed adding rockchip_setup_macaddr() back is fine. Let's use rockchip_early_misc_init_r instead of reimplementing the whole misc_init_r from Rockchip (the side effect being that rockchip_setup_macaddr() is back). We might actually introduce some issues with this change. I'll get back later with a more detailed explanation, together with a proposed fix, after I check it all in detail. This applies to some other patches in this series as well. I assume this is specifically about the migration to rockchip_early_misc_init_r? What's the issue? And for which devices? I don't really need this patch, it's just to avoid code duplication in a later patch but I'd rather not have this block this patch series. We can always revisit this in a separate patch series which can take as long as we want. I should be able to provide all the details later today or tomorrow, together with the proposed fix. Perhaps such a timeline should be acceptable, by not introducing some significant delays.
Re: [PATCH 06/18] rockchip: pine64: pinebook: migrate to rockchip_early_misc_init_r
Hi Dragan, On 2/1/24 05:02, Dragan Simic wrote: [Some people who received this message don't often get email from dsi...@manjaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hello Kever and Quentin, On 2024-02-01 03:48, Kever Yang wrote: On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Compared to the original misc_init_r from Rockchip mach code, setup_iodomain() is added and rockchip_setup_macaddr() is not called. It is assumed adding rockchip_setup_macaddr() back is fine. Let's use rockchip_early_misc_init_r instead of reimplementing the whole misc_init_r from Rockchip (the side effect being that rockchip_setup_macaddr() is back). We might actually introduce some issues with this change. I'll get back later with a more detailed explanation, together with a proposed fix, after I check it all in detail. This applies to some other patches in this series as well. I assume this is specifically about the migration to rockchip_early_misc_init_r? What's the issue? And for which devices? I don't really need this patch, it's just to avoid code duplication in a later patch but I'd rather not have this block this patch series. We can always revisit this in a separate patch series which can take as long as we want. Cheers, Quentin
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On Thu, 1 Feb 2024 09:39:54 + Shantur Rathore wrote: Hi Shantur, > On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara wrote: > > > > On Sat, 9 Dec 2023 18:10:56 + > > Shantur Rathore wrote: > > > > Hi, > > > > > Currently when a hub is turned on, all the ports are powered on. > > > This works well for hubs which have individual power control. > > > > > > For the hubs without individual power control this has no effect. > > > Mostly in these scenarios the hub port is powered before the USB > > > controller is enabled, this can lead to some devices in unexpected > > > state. > > > > > > With this patch, we explicitly reset the port while powering up hub > > > This resets the port for hubs without port power control and has > > > no effect on hubs with port power control as the port is still off. > > > > > > Before this patch AMicro AM8180 based NVME to USB adapter won't be > > > detected as a USB3.0 Mass Storage device but with this it works as > > > expected. > > > > > > Tested working after this patch: > > > 1. AMicro AM8180 based NVME to USB Adapter > > > 2. Kingston DataTraveler 3.0 > > > 3. GenesysLogic USB3.0 Hub > > > > > > The drives were tested while connected directly and via the hub. > > > > so this broke USB operation on some Allwinner boards. The ports still > > enumerate correctly, but no devices are detected. With mainline > > (containing this patch), and a USB stick connected: > > starting USB... > > Bus usb@520: USB EHCI 1.00 > > Bus usb@5200400: USB OHCI 1.0 > > scanning bus usb@520 for devices... 1 USB Device(s) found > > scanning bus usb@5200400 for devices... 1 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > > > > With this patch here reverted: > > starting USB... > > Bus usb@520: USB EHCI 1.00 > > Bus usb@5200400: USB OHCI 1.0 > > scanning bus usb@520 for devices... 2 USB Device(s) found > > scanning bus usb@5200400 for devices... 1 USB Device(s) found > >scanning usb for storage devices... 1 Storage Device(s) found > > > > I have no clue why this happens, there is no discrete hub anywhere in this > > setup, so I guess the code runs for the root hub here? > > I am attaching a log with DEBUG enabled for common/usb_hub.c, for both > > cases. > > > > Any clues, debug suggestions, or even a fix are warmly welcome. > > > > Which USB disk are you using? Is it a USB 2.0 disk ? > Can you try with any other USB disk to confirm? Yes, this was some USB 2.0 memory stick, on an USB 2.0 port. Most sunxi boards only have USB 2.0, but there is one SoC with USB 3.0, I will try some combinations later tonight. Thanks, Andre
Re: [PATCH 1/1] sunxi: sun4i: Introduce KConfig option SPL_SYS_CLK_FREQ
On Thu, 1 Feb 2024 14:30:14 +0100
Ludwig Kormann wrote:
Hi,
> This option can be used to modify the initial SPL
> CPU clock frequency.
>
> This follows an earlier discussion regarding A20
> CPUs dying after reboot in SPL initialization due to
> incompatible CPU clock frequency and core voltage. [1]
>
> First attempt was to update PLL1_CFG_DEFAULT to a fixed
> lower frequency (144MHz), which fixed the observed issue
> but might not suit all A20 users. A KConfig option
> should be the better solution.
Can you please reword this to include more vital information directly in
the commit message? We had mailing list archives vanish in the past.
Please mention that our default frequency of 384 MHz does not work at
every voltage, and after just a core reset the PMIC might still use a
previously programmed lower voltage, that will hang the SPL, on some
batches of chips.
> [1]
> https://lists.denx.de/pipermail/u-boot/2024-January/544897.html
Please use the Link: tag:
Link: https://lists.denx.de/
>
> Signed-off-by: Ludwig Kormann
> ---
> arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 4
> arch/arm/mach-sunxi/Kconfig | 8
> arch/arm/mach-sunxi/clock_sun4i.c | 11 ++-
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
> index 2cec91cb20..11b350824e 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
> @@ -134,12 +134,16 @@ struct sunxi_ccm_reg {
> #define CCM_PLL1_CFG_PLL4_EXCH_SHIFT 25
> #define CCM_PLL1_CFG_BIAS_CUR_SHIFT 20
> #define CCM_PLL1_CFG_DIVP_SHIFT 16
> +#define CCM_PLL1_CFG_DIVP_MASK (0x3 <<
> CCM_PLL1_CFG_DIVP_SHIFT)
> #define CCM_PLL1_CFG_LCK_TMR_SHIFT 13
> #define CCM_PLL1_CFG_FACTOR_N_SHIFT 8
> +#define CCM_PLL1_CFG_FACTOR_N_MASK (0x1f <<
> CCM_PLL1_CFG_FACTOR_N_SHIFT)
> #define CCM_PLL1_CFG_FACTOR_K_SHIFT 4
> +#define CCM_PLL1_CFG_FACTOR_K_MASK (0x3 <<
> CCM_PLL1_CFG_FACTOR_K_SHIFT)
> #define CCM_PLL1_CFG_SIG_DELT_PAT_IN_SHIFT 3
> #define CCM_PLL1_CFG_SIG_DELT_PAT_EN_SHIFT 2
> #define CCM_PLL1_CFG_FACTOR_M_SHIFT 0
> +#define CCM_PLL1_CFG_FACTOR_M_MASK (0x3 <<
> CCM_PLL1_CFG_FACTOR_M_SHIFT)
>
> #define PLL1_CFG_DEFAULT 0xa1005000
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index fe89aec6b9..85e3a26855 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -705,6 +705,14 @@ config SYS_CLK_FREQ
> default 100800 if MACH_SUN50I_H616
> default 100800 if MACH_SUN8I_R528
>
> +if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
As Tom already mentioned, please use "depends on".
> +config SPL_SYS_CLK_FREQ
> + int "sunxi SPL CPU clock frequency"
"sunxi" is redundant here. Please state that this is the early SPL
frequency, since we switch to SYS_CLK_FREQ in the SPL still, only later.
> + default 384
> + ---help---
> + A static value for the sunxi SPL CPU frequency, must be a multiple of 24.
Minus sunxi, plus early, as above. Also please mention the safe frequency
(144 MHz) here, as a recommendation if people experience problems.
> +endif
> +
> config SYS_CONFIG_NAME
> default "suniv" if MACH_SUNIV
> default "sun4i" if MACH_SUN4I
> diff --git a/arch/arm/mach-sunxi/clock_sun4i.c
> b/arch/arm/mach-sunxi/clock_sun4i.c
> index 8f1d1b65f0..04623c1d09 100644
> --- a/arch/arm/mach-sunxi/clock_sun4i.c
> +++ b/arch/arm/mach-sunxi/clock_sun4i.c
> @@ -25,7 +25,16 @@ void clock_init_safe(void)
> APB0_DIV_1 << APB0_DIV_SHIFT |
> CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
> >cpu_ahb_apb0_cfg);
> - writel(PLL1_CFG_DEFAULT, >pll1_cfg);
> + writel((PLL1_CFG_DEFAULT &
> + ~(CCM_PLL1_CFG_FACTOR_N_MASK |
> + CCM_PLL1_CFG_FACTOR_K_MASK |
> + CCM_PLL1_CFG_FACTOR_M_MASK |
> + CCM_PLL1_CFG_DIVP_MASK)) |
> + (CONFIG_SPL_SYS_CLK_FREQ / 24) << CCM_PLL1_CFG_FACTOR_N_SHIFT |
> + 0 << CCM_PLL1_CFG_FACTOR_K_SHIFT |
> + 0 << CCM_PLL1_CFG_FACTOR_M_SHIFT |
> + 0 << CCM_PLL1_CFG_DIVP_SHIFT,
> + >pll1_cfg);
There is already the PLL1_CFG macro later in that same file, can you reuse
that, maybe?
Otherwise this is indeed what I had in mind, thanks for providing the
patch!
Cheers,
Andre
> sdelay(200);
> writel(AXI_DIV_1 << AXI_DIV_SHIFT |
> AHB_DIV_2 << AHB_DIV_SHIFT |
[PATCH 1/1] doc: board: starfive: fix rendering of OpenSBI logo
The rendering of the OpenSBI logo should look like the screen output. Signed-off-by: Heinrich Schuchardt --- doc/board/starfive/visionfive2.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/board/starfive/visionfive2.rst b/doc/board/starfive/visionfive2.rst index 6cb033ead04..abda8ac21bc 100644 --- a/doc/board/starfive/visionfive2.rst +++ b/doc/board/starfive/visionfive2.rst @@ -133,14 +133,14 @@ Sample boot log from StarFive VisionFive2 board Trying to boot from MMC2 OpenSBI v1.2-80-g4b28afc - _ _ - / __ \ / | _ \_ _| + _ _ +/ __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ - \/| .__/ \___|_| |_|_/|___/_| - | | - |_| +\/| .__/ \___|_| |_|_/|/_| + | | + |_| Platform Name : StarFive VisionFive 2 v1.3B Platform Features : medeleg -- 2.43.0
Re: [PATCH 1/1] sunxi: sun4i: add missing sdelay() to clock_init_safe()
On Thu, 1 Feb 2024 09:45:50 +0100 Ludwig Kormann wrote: Hi, > This delay is required after switching the clock source. > > See “A20 Reference manual v1.4” Page 50 / section > “1.5.4.16. CPU/AHB/APB0 CLOCK RATIO”: “If the clock > source is changed, at most to wait for 8 present running > clock cycles.” > > This is already implemented in clock_set_pll1(), but was > still missing in clock_init_safe(). > > Signed-off-by: Ludwig Kormann Good catch, thanks for sending this! Reviewed-by: Andre Przywara Cheers, Andre > --- > arch/arm/mach-sunxi/clock_sun4i.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/mach-sunxi/clock_sun4i.c > b/arch/arm/mach-sunxi/clock_sun4i.c > index 8f1d1b65f0..ac3b7a801f 100644 > --- a/arch/arm/mach-sunxi/clock_sun4i.c > +++ b/arch/arm/mach-sunxi/clock_sun4i.c > @@ -25,6 +25,7 @@ void clock_init_safe(void) > APB0_DIV_1 << APB0_DIV_SHIFT | > CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT, > >cpu_ahb_apb0_cfg); > + sdelay(20); > writel(PLL1_CFG_DEFAULT, >pll1_cfg); > sdelay(200); > writel(AXI_DIV_1 << AXI_DIV_SHIFT | > @@ -32,6 +33,7 @@ void clock_init_safe(void) > APB0_DIV_1 << APB0_DIV_SHIFT | > CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT, > >cpu_ahb_apb0_cfg); > + sdelay(20); > #ifdef CONFIG_MACH_SUN7I > setbits_le32(>ahb_gate0, 0x1 << AHB_GATE_OFFSET_DMA); > #endif
Re: [PATCH v1] doc: imx: imxrt1170: Document imxrt1170-evk board
Hi Jesse, On 01/02/24 16:00, Jesse Taube wrote: Add documentation for imxrt1170-evk. Signed-off-by: Jesse Taube looks good to me Reviewed-by: Giulio Benetti Best regards -- Giulio Benetti CEO@Benetti Engineering sas --- doc/board/nxp/imxrt1170-evk.rst | 42 + 1 file changed, 42 insertions(+) create mode 100644 doc/board/nxp/imxrt1170-evk.rst diff --git a/doc/board/nxp/imxrt1170-evk.rst b/doc/board/nxp/imxrt1170-evk.rst new file mode 100644 index 00..4acccdcc93 --- /dev/null +++ b/doc/board/nxp/imxrt1170-evk.rst @@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +imxrt1170-evk += + +How to use U-Boot on NXP i.MXRT1170 EVK +--- + +- Build U-Boot for i.MXRT1170 EVK: + +.. code-block:: bash + + $ make mrproper + $ make imxrt1170-evk_defconfig + $ make + +This will generate the SPL image called SPL and the u-boot.img. + +- Flash the SPL image into the micro SD card: + +.. code-block:: bash + + $sudo dd if=SPL of=/dev/sdX bs=1k seek=1 conv=notrunc; sync + +- Flash the u-boot.img image into the micro SD card: + +.. code-block:: bash + + $sudo dd if=u-boot.img of=/dev/sdX bs=1k seek=128 conv=notrunc; sync + +- Jumper settings:: + + SW1: 1 0 1 0 + SW2: 0 0 0 0 0 0 0 0 1 0 0 0 + +where 0 means bottom position and 1 means top position (from the +switch label numbers reference). + +- Connect the USB cable between the EVK and the PC for the console. + The USB console connector is the one close the ethernet connector + +- Insert the micro SD card in the board, power it up and U-Boot messages should come up.
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On Thu, Feb 1, 2024 at 2:53 PM Marek Vasut wrote: > > On 2/1/24 12:18, Shantur Rathore wrote: > > On Thu, Feb 1, 2024 at 11:13 AM Marek Vasut wrote: > >> > >> On 2/1/24 10:39, Shantur Rathore wrote: > >>> Hi Andre, > >>> > >>> On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara > >>> wrote: > > On Sat, 9 Dec 2023 18:10:56 + > Shantur Rathore wrote: > > Hi, > > > Currently when a hub is turned on, all the ports are powered on. > > This works well for hubs which have individual power control. > > > > For the hubs without individual power control this has no effect. > > Mostly in these scenarios the hub port is powered before the USB > > controller is enabled, this can lead to some devices in unexpected > > state. > > > > With this patch, we explicitly reset the port while powering up hub > > This resets the port for hubs without port power control and has > > no effect on hubs with port power control as the port is still off. > > > > Before this patch AMicro AM8180 based NVME to USB adapter won't be > > detected as a USB3.0 Mass Storage device but with this it works as > > expected. > > > > Tested working after this patch: > > 1. AMicro AM8180 based NVME to USB Adapter > > 2. Kingston DataTraveler 3.0 > > 3. GenesysLogic USB3.0 Hub > > > > The drives were tested while connected directly and via the hub. > > so this broke USB operation on some Allwinner boards. The ports still > enumerate correctly, but no devices are detected. With mainline > (containing this patch), and a USB stick connected: > starting USB... > Bus usb@520: USB EHCI 1.00 > Bus usb@5200400: USB OHCI 1.0 > scanning bus usb@520 for devices... 1 USB Device(s) found > scanning bus usb@5200400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > > With this patch here reverted: > starting USB... > Bus usb@520: USB EHCI 1.00 > Bus usb@5200400: USB OHCI 1.0 > scanning bus usb@520 for devices... 2 USB Device(s) found > scanning bus usb@5200400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > > I have no clue why this happens, there is no discrete hub anywhere in > this > setup, so I guess the code runs for the root hub here? > I am attaching a log with DEBUG enabled for common/usb_hub.c, for both > cases. > > Any clues, debug suggestions, or even a fix are warmly welcome. > > >>> > >>> Which USB disk are you using? Is it a USB 2.0 disk ? > >>> Can you try with any other USB disk to confirm? > >> > >> I don't think this is device specific, see the logs. Hardware from Andre > >> worked before this patch, does not work after this patch. There seem to > >> be no connection event with this patch. > > > > I am trying to evaluate if this is happening due to a USB 2.0 device. > > I see that the host is USB 2.0. I have tested this on my RK3399 board on > > both > > USB 2.0 and USB 3.0 ports. > > If this is not behaving on USB 2.0 ports then I can put a condition > > for this to happen > > only on USB 3.0 ports. > > Doesn't Linux perform this reset for all ports unconditionally ? Looks like it doesn't https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2841
Re: [GIT PULL] Please pull u-boot-amlogic-fixes-20240201
On Thu, Feb 01, 2024 at 03:26:25PM +0100, Neil Armstrong wrote: > Hi Tom, > > Please pull this simple fix avoiding printing the board model twice. > > Thanks, > Neil > > The following changes since commit 6faba41927bdc8973b59678649ef83c564cc421e: > > Prepare v2024.04-rc1 (2024-01-29 20:53:19 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-fixes-20240201 > > for you to fetch changes up to 076529725f16f07a5cb2d5feba25d62b5f5a5872: > > ARM: meson: stop printing board model after sysinfo update (2024-01-30 > 09:35:51 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-watchdog/master
On Thu, Feb 01, 2024 at 11:50:43AM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the following watchdog related last minute fixes: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] sunxi: sun4i: Introduce KConfig option SPL_SYS_CLK_FREQ
On Thu, Feb 01, 2024 at 02:30:14PM +0100, Ludwig Kormann wrote: > This option can be used to modify the initial SPL > CPU clock frequency. > > This follows an earlier discussion regarding A20 > CPUs dying after reboot in SPL initialization due to > incompatible CPU clock frequency and core voltage. [1] > > First attempt was to update PLL1_CFG_DEFAULT to a fixed > lower frequency (144MHz), which fixed the observed issue > but might not suit all A20 users. A KConfig option > should be the better solution. > > [1] > https://lists.denx.de/pipermail/u-boot/2024-January/544897.html > > Signed-off-by: Ludwig Kormann [snip] > +if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I > +config SPL_SYS_CLK_FREQ > + int "sunxi SPL CPU clock frequency" > + default 384 > + ---help--- > + A static value for the sunxi SPL CPU frequency, must be a multiple of 24. > +endif This should really just be "depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I" and then "help". -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH v2 2/2] board: ad401: example of fastboot oem board realization
Hi,
On Thu, Feb 01, 2024 at 04:56:34PM +0300, Dan Carpenter wrote:
> On Thu, Feb 01, 2024 at 12:20:27PM +0300, Alexey Romanov wrote:
> > +static int fastboot_nand_write_tpl(struct mtd_info *mtd, void *buffer,
> > + u32 offset, size_t size, int flags)
> > +{
> > + int boot_cpy_num = meson_bootloader_copy_num(BOOT_TPL);
> > + u64 size_per_copy = meson_bootloader_copy_size(mtd, BOOT_TPL);
> > + int i;
> > +
> > + for (i = 0; i < boot_cpy_num; i++) {
> > + size_t retlen, len = size;
> > + int ret;
> > +
> > + ret = nand_write_skip_bad(mtd, offset + (i * size_per_copy),
> > + , , offset + size_per_copy,
>
> ^^
> Sorry if I'm missing something obvious, but why is the limit
> "offset + size_per_copy"? I would have expected it to be just
> "size_per_copy" or maybe some kind of limit minus the offset...
Yeah, this is incorrect. Should be size_per_copy.
But this patch is just an example of realization.
>
> > + buffer, flags);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
>
> regards,
> dan carpenter
>
--
Thank you,
Alexey
Re: [PATCH 0/3] usb: ehci-generic: setup a bulk of phy when possible
On 2/1/2024 10:07 PM, Marek Vasut wrote: On 2/1/24 14:16, Yang Xiwen via B4 Relay wrote: one USB controller can have multiple ports specified in dts, all of them should be setup to make use of all possible ports. Is there an example of such a system ? I'm going to send one, but not now because of some stuck patches. Running `grep 'phys = <.*>, <.*>' arch/arm/dts/*.dtsi` in the dts directory gives us some existing examples, though not very much. -- Regards, Yang Xiwen
[PATCH v1] doc: imx: imxrt1170: Document imxrt1170-evk board
Add documentation for imxrt1170-evk. Signed-off-by: Jesse Taube --- doc/board/nxp/imxrt1170-evk.rst | 42 + 1 file changed, 42 insertions(+) create mode 100644 doc/board/nxp/imxrt1170-evk.rst diff --git a/doc/board/nxp/imxrt1170-evk.rst b/doc/board/nxp/imxrt1170-evk.rst new file mode 100644 index 00..4acccdcc93 --- /dev/null +++ b/doc/board/nxp/imxrt1170-evk.rst @@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +imxrt1170-evk += + +How to use U-Boot on NXP i.MXRT1170 EVK +--- + +- Build U-Boot for i.MXRT1170 EVK: + +.. code-block:: bash + + $ make mrproper + $ make imxrt1170-evk_defconfig + $ make + +This will generate the SPL image called SPL and the u-boot.img. + +- Flash the SPL image into the micro SD card: + +.. code-block:: bash + + $sudo dd if=SPL of=/dev/sdX bs=1k seek=1 conv=notrunc; sync + +- Flash the u-boot.img image into the micro SD card: + +.. code-block:: bash + + $sudo dd if=u-boot.img of=/dev/sdX bs=1k seek=128 conv=notrunc; sync + +- Jumper settings:: + + SW1: 1 0 1 0 + SW2: 0 0 0 0 0 0 0 0 1 0 0 0 + +where 0 means bottom position and 1 means top position (from the +switch label numbers reference). + +- Connect the USB cable between the EVK and the PC for the console. + The USB console connector is the one close the ethernet connector + +- Insert the micro SD card in the board, power it up and U-Boot messages should come up. -- 2.43.0
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On 2/1/24 12:18, Shantur Rathore wrote: On Thu, Feb 1, 2024 at 11:13 AM Marek Vasut wrote: On 2/1/24 10:39, Shantur Rathore wrote: Hi Andre, On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara wrote: On Sat, 9 Dec 2023 18:10:56 + Shantur Rathore wrote: Hi, Currently when a hub is turned on, all the ports are powered on. This works well for hubs which have individual power control. For the hubs without individual power control this has no effect. Mostly in these scenarios the hub port is powered before the USB controller is enabled, this can lead to some devices in unexpected state. With this patch, we explicitly reset the port while powering up hub This resets the port for hubs without port power control and has no effect on hubs with port power control as the port is still off. Before this patch AMicro AM8180 based NVME to USB adapter won't be detected as a USB3.0 Mass Storage device but with this it works as expected. Tested working after this patch: 1. AMicro AM8180 based NVME to USB Adapter 2. Kingston DataTraveler 3.0 3. GenesysLogic USB3.0 Hub The drives were tested while connected directly and via the hub. so this broke USB operation on some Allwinner boards. The ports still enumerate correctly, but no devices are detected. With mainline (containing this patch), and a USB stick connected: starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found With this patch here reverted: starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found I have no clue why this happens, there is no discrete hub anywhere in this setup, so I guess the code runs for the root hub here? I am attaching a log with DEBUG enabled for common/usb_hub.c, for both cases. Any clues, debug suggestions, or even a fix are warmly welcome. Which USB disk are you using? Is it a USB 2.0 disk ? Can you try with any other USB disk to confirm? I don't think this is device specific, see the logs. Hardware from Andre worked before this patch, does not work after this patch. There seem to be no connection event with this patch. I am trying to evaluate if this is happening due to a USB 2.0 device. I see that the host is USB 2.0. I have tested this on my RK3399 board on both USB 2.0 and USB 3.0 ports. If this is not behaving on USB 2.0 ports then I can put a condition for this to happen only on USB 3.0 ports. Doesn't Linux perform this reset for all ports unconditionally ?
Re: [PATCH 0/3] usb: ehci-generic: setup a bulk of phy when possible
On 2/1/24 14:16, Yang Xiwen via B4 Relay wrote: one USB controller can have multiple ports specified in dts, all of them should be setup to make use of all possible ports. Is there an example of such a system ?
Re: [PATCH v3 20/36] mach-snapdragon: carve out no-map regions
On 01/02/2024 12:07, Sumit Garg wrote:
> On Tue, 30 Jan 2024 at 19:35, Caleb Connolly
> wrote:
>>
>> On Qualcomm platforms, the TZ may already have certain memory regions
>> under protection by the time U-Boot starts. There is a rare case on some
>> platforms where the prefetcher might speculatively access one of these
>> regions resulting in a board crash (TZ traps and then resets the board).
>>
>> We shouldn't be accessing these regions from within U-Boot anyway, so
>> let's mark them all with PTE_TYPE_FAULT to prevent any speculative
>> access and correctly trap in EL1 rather than EL3.
>>
>> This is quite costly with caches off (takes ~2 seconds on SDM845 vs 35ms
>> with caches on). So to minimise the impact this is only enabled on
>> QCS404 for now (where the issue is known to occur).
>
> It only took 65ms with caches off on QCS404 as per below print:
>
> carveout time: 65ms
>
> It's probably due to some missing bits as pointed below to get it
> working fast on SDM845 too..
Ah I didn't consider that the difference might really just be the 2M vs
4K alignment.
[snip]
>> +
>> +/* Mark all no-map regions as PTE_TYPE_FAULT to prevent speculative access.
>> + * On some platforms this is enough to trigger a security violation and trap
>> + * to EL3.
>> + */
>> +static void carve_out_reserved_memory(void)
>> +{
>> + static struct fdt_resource res[N_RESERVED_REGIONS] = { 0 };
>> + int parent, rmem, count, i = 0;
>> + phys_addr_t start;
>> + size_t size;
>> +
>> + /* Some reserved nodes must be carved out, as the cache-prefetcher
>> may otherwise
>> +* attempt to access them, causing a security exception.
>> +*/
>> + parent = fdt_path_offset(gd->fdt_blob, "/reserved-memory");
>> + if (parent <= 0) {
>> + log_err("No reserved memory regions found\n");
>> + return;
>> + }
>> + count = fdtdec_get_child_count(gd->fdt_blob, parent);
>> + if (count > N_RESERVED_REGIONS) {
>> + log_err("Too many reserved memory regions!\n");
>> + count = N_RESERVED_REGIONS;
>> + }
>> +
>> + /* Collect the reserved memory regions */
>> + fdt_for_each_subnode(rmem, gd->fdt_blob, parent) {
>> + if (!fdt_getprop(gd->fdt_blob, rmem, "no-map", NULL))
>> + continue;
>> + if (fdt_getprop(gd->fdt_blob, rmem, "compatible", NULL))
>> + continue;
>> + /* Skip regions that don't have a fixed address/size */
>> + if (fdt_get_resource(gd->fdt_blob, rmem, "reg", 0,
>> [i++]))
>> + i--;
>> + }
>> +
>> + /* Sort the reserved memory regions by address */
>> + count = i;
>> + qsort(res, count, sizeof(struct fdt_resource), fdt_cmp_res);
>> +
>> + /* Now set the right attributes for them. Often a lot of the regions
>> are tightly packed together
>> +* so we can optimise the number of calls to
>> mmu_change_region_attr() by combining adjacent
>> +* regions.
>> +*/
>> + start = ALIGN_DOWN(res[0].start, SZ_2M);
>> + size = ALIGN(res[0].end, SZ_4K) - start;
>> + for (i = 1; i < count; i++) {
>
> I suppose this loop fails to configure attributes for the last no-map
> region like uefi_mem region on QCS404.
Right.
>
>> + /* We ideally want to 2M align everything for more efficient
>> pagetables, but we must avoid
>> +* overwriting reserved memory regions which shouldn't be
>> mapped as FAULT (like those with
>> +* compatible properties).
>> +* If within 2M of the previous region, bump the size to
>> include this region. Otherwise
>> +* start a new region.
>> +*/
>> + if (start + size < res[i].start - SZ_2M) {
>> + debug(" 0x%016llx - 0x%016llx FAULT\n",
>> + start, start + size);
>> + mmu_change_region_attr(start, size, PTE_TYPE_FAULT);
>
> Here the size won't always be 2M aligned which is the case for SDM845.
> I would suggest you do:
>
> mmu_change_region_attr(start, ALIGN(size,
> SZ_2M), PTE_TYPE_FAULT);
This isn't an option as I want to avoid unmapping reserved memory
regions which have a compatible property; on SDM845 for example this
includes the cmd-db and rmtfs regions. These are not 2M aligned and
might be directly adjacent to other regions, so doing an align here
could result in unmapping part of these regions.
This will be especially relevant for SM8250 where I'll be enabling
cmd-db and RPMh drivers in order to turn on the USB VBUS regulator on RB5.
>
> -Sumit
>
>> + start = ALIGN_DOWN(res[i].start, SZ_2M);
>> + size = ALIGN(res[i].end, SZ_4K) - start;
>> + } else {
>> + /* Bump size if this region is
Re: [PATCH v2 02/13] power: domain: ti: use IS_ENABLED macro
On Thu, Feb 1, 2024 at 4:07 AM Bryan Brattlof wrote:
>
> Cleanup this list and standardize on using the IS_ENABLED macro for the
> power domain data list.
>
> Signed-off-by: Bryan Brattlof
> ---
> drivers/power/domain/ti-power-domain.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/domain/ti-power-domain.c
> b/drivers/power/domain/ti-power-domain.c
> index b34c982f4f5fa..dc5d74539edcf 100644
> --- a/drivers/power/domain/ti-power-domain.c
> +++ b/drivers/power/domain/ti-power-domain.c
> @@ -81,19 +81,20 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
> .family = "J7200",
> .data = _pd_platdata,
> },
> -#elif CONFIG_SOC_K3_J721S2
> +#endif
> +#if IS_ENABLED(CONFIG_SOC_K3_J721S2)
> {
> .family = "J721S2",
> .data = _pd_platdata,
> },
> #endif
> -#ifdef CONFIG_SOC_K3_AM625
> +#if IS_ENABLED(CONFIG_SOC_K3_AM625)
> {
> .family = "AM62X",
> .data = _pd_platdata,
> },
> #endif
> -#ifdef CONFIG_SOC_K3_AM62A7
> +#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
> {
> .family = "AM62AX",
> .data = _pd_platdata,
> --
> 2.43.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Senior Software Engineer, Embedded & Security
E: igor.opan...@foundries.io
W: www.foundries.io
Re: [PATCH v2 01/13] soc: add info to identify the am62p SoC family
On Thu, Feb 1, 2024 at 4:07 AM Bryan Brattlof wrote: > > Include the part number for TI's am62px family of SoCs so we can > properly identify it during boot > > Signed-off-by: Bryan Brattlof Reviewed-by: Igor Opaniuk > --- > arch/arm/mach-k3/include/mach/hardware.h | 2 ++ > drivers/soc/soc_ti_k3.c | 3 +++ > 2 files changed, 5 insertions(+) > > diff --git a/arch/arm/mach-k3/include/mach/hardware.h > b/arch/arm/mach-k3/include/mach/hardware.h > index a1a9dfbde66c8..040288150b12f 100644 > --- a/arch/arm/mach-k3/include/mach/hardware.h > +++ b/arch/arm/mach-k3/include/mach/hardware.h > @@ -46,6 +46,7 @@ > #define JTAG_ID_PARTNO_J721S2 0xbb75 > #define JTAG_ID_PARTNO_AM62X 0xbb7e > #define JTAG_ID_PARTNO_AM62AX 0xbb8d > +#define JTAG_ID_PARTNO_AM62PX 0xbb9d > > #define K3_SOC_ID(id, ID) \ > static inline bool soc_is_##id(void) \ > @@ -61,6 +62,7 @@ K3_SOC_ID(am64x, AM64X) > K3_SOC_ID(j721s2, J721S2) > K3_SOC_ID(am62x, AM62X) > K3_SOC_ID(am62ax, AM62AX) > +K3_SOC_ID(am62px, AM62PX) > > #define K3_SEC_MGR_SYS_STATUS 0x44234100 > #define SYS_STATUS_DEV_TYPE_SHIFT 0 > diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c > index 355a5368dd45a..d7d0152b115fa 100644 > --- a/drivers/soc/soc_ti_k3.c > +++ b/drivers/soc/soc_ti_k3.c > @@ -45,6 +45,9 @@ static const char *get_family_string(u32 idreg) > case JTAG_ID_PARTNO_AM62AX: > family = "AM62AX"; > break; > + case JTAG_ID_PARTNO_AM62PX: > + family = "AM62PX"; > + break; > default: > family = "Unknown Silicon"; > }; > -- > 2.43.0 > -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk Senior Software Engineer, Embedded & Security E: igor.opan...@foundries.io W: www.foundries.io
Re: [PATCH v3 17/36] mach-snapdragon: generalise board support
[snip]
>> diff --git a/configs/dragonboard845c_defconfig
>> b/configs/dragonboard845c_defconfig
>> deleted file mode 100644
>> index f29f11e342e7..
>> --- a/configs/dragonboard845c_defconfig
>> +++ /dev/null
>> @@ -1,29 +0,0 @@
>> -CONFIG_ARM=y
>> -CONFIG_SKIP_LOWLEVEL_INIT=y
>> -CONFIG_COUNTER_FREQUENCY=1900
>> -CONFIG_POSITION_INDEPENDENT=y
>> -CONFIG_ARCH_SNAPDRAGON=y
>> -CONFIG_DEFAULT_DEVICE_TREE="dragonboard845c"
>> -CONFIG_TARGET_DRAGONBOARD845C=y
>> -CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 845C"
>> -CONFIG_SYS_LOAD_ADDR=0x8000
>> -CONFIG_FIT=y
>> -CONFIG_FIT_VERBOSE=y
>> -CONFIG_BOOTDELAY=5
>> -CONFIG_SAVE_PREV_BL_FDT_ADDR=y
>> -CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR=y
>
> I would suggest keeping this config option in new qcom_defconfig since
> it allows to package FIT image as intramfs within boot.img...
Ah for sure, nice catch.
I know this is a pretty huge patch, but for future reference please
could you trim down irrelevant stuff when replying? Otherwise it's easy
to miss your comments...
[snip]
>> diff --git a/include/configs/qcom.h b/include/configs/qcom.h
>> new file mode 100644
>> index ..e50b3bce5cdd
>> --- /dev/null
>> +++ b/include/configs/qcom.h
>> @@ -0,0 +1,21 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * Configuration file for Qualcomm Snapdragon boards
>> + *
>> + * (C) Copyright 2021 Dzmitry Sankouski
>> + * (C) Copyright 2023 Linaro Ltd.
>> + */
>> +
>> +#ifndef __CONFIGS_SNAPDRAGON_H
>> +#define __CONFIGS_SNAPDRAGON_H
>> +
>> +#define CFG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600 }
>> +
>> +/* Load addressed are calculated during board_late_init(). See
>> arm/mach-snapdragon/board.c */
>> +#define CFG_EXTRA_ENV_SETTINGS \
>> + "stdin=serial,button-kbd\0" \
>> + "stdout=serial,vidconsole\0"\
>> + "stderr=serial,vidconsole\0" \
>> + "bootcmd=bootm $prevbl_initrd_start_addr\0"
>
> ...as otherwise this bootcmd won't work.
>
> -Sumit
>
>> +
--
// Caleb (they/them)
Re: [PATCH v3 1/3] firmware: psci: Fix bind_smccc_features psci check
Hello Weizhao, On Wed, Jan 31, 2024 at 3:15 PM Weizhao Ouyang wrote: > > According to PSCI specification DEN0022F, PSCI_FEATURES is used to check > whether the SMCCC is implemented by discovering SMCCC_VERSION. > Could you please add more details to your commit message or as a comment explaining what exact steps should be done for a full discovery sequence of Arm Architecture Service functions, so people don't need to search for that information explicitly? For instance: Step 1: Determine if SMCCC_VERSION is implemented - Use firmware data, device tree PSCI node, or ACPI FADT PSCI flag, to determine whether a PSCI implementation is present. - Use PSCI_VERSION to learn whether PSCI_FEATURES is provided. PSCI_FEATURES is mandatory from version 1.0 of PSCI Step 2. etc. I would just pull that info from the latest SMC Calling Convention version 1.5, from 9 Appendix B: Discovery of Arm Architecture Service functions. Thank you! > Signed-off-by: Weizhao Ouyang > --- > v3: remove fallback smc call > v2: check SMCCC_ARCH_FEATURES > --- > drivers/firmware/psci.c | 5 - > include/linux/arm-smccc.h | 6 ++ > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c > index c6b9efab41..03544d76ed 100644 > --- a/drivers/firmware/psci.c > +++ b/drivers/firmware/psci.c > @@ -135,10 +135,13 @@ static int bind_smccc_features(struct udevice *dev, int > psci_method) > PSCI_VERSION_MAJOR(psci_0_2_get_version()) == 0) > return 0; > > - if (request_psci_features(ARM_SMCCC_ARCH_FEATURES) == > + if (request_psci_features(ARM_SMCCC_VERSION) == > PSCI_RET_NOT_SUPPORTED) > return 0; > > + if (invoke_psci_fn(ARM_SMCCC_VERSION, 0, 0, 0) < > ARM_SMCCC_VERSION_1_1) > + return 0; > + IMO, to fully comply with SMC Calling Convention version 1.5 we should also check for SMCCC_ARCH_WORKAROUND_1: >From 9 Appendix B: Discovery of Arm Architecture Service functions, Step 2: Determine if Arm Architecture Service function is implemented - Use SMCCC_VERSION to learn whether the calling convention complies to version 1.1 or above. - Use SMCCC_ARCH_FEATURES to query whether the Arm Architecture Service function is implemented on this system <--- we lack of this step > if (psci_method == PSCI_METHOD_HVC) > pdata->invoke_fn = smccc_invoke_hvc; > else > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h > index f44e9e8f93..da3d29aabe 100644 > --- a/include/linux/arm-smccc.h > +++ b/include/linux/arm-smccc.h > @@ -55,8 +55,14 @@ > #define ARM_SMCCC_QUIRK_NONE 0 > #define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register a6 > */ > > +#define ARM_SMCCC_VERSION 0x8000 > #define ARM_SMCCC_ARCH_FEATURES0x8001 > > +#define ARM_SMCCC_VERSION_1_0 0x1 > +#define ARM_SMCCC_VERSION_1_1 0x10001 > +#define ARM_SMCCC_VERSION_1_2 0x10002 > +#define ARM_SMCCC_VERSION_1_3 0x10003 > + > #define ARM_SMCCC_RET_NOT_SUPPORTED((unsigned long)-1) > > #ifndef __ASSEMBLY__ > -- > 2.39.2 > -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk Senior Software Engineer, Embedded & Security E: igor.opan...@foundries.io W: www.foundries.io
Re: [PATCH v3 03/36] mmc: msm_sdhci: use modern clock handling
On 01/02/2024 08:19, Sumit Garg wrote:
> On Tue, 30 Jan 2024 at 19:35, Caleb Connolly
> wrote:
>>
>> Use the clk_* helper functions and the correct property name for clocks.
>
> This still doesn't handle fixed clocks like in case of QCS404, upstream DT
> says:
>
> sdcc1: mmc@7804000 {
> compatible = "qcom,qcs404-sdhci", "qcom,sdhci-msm-v5";
> ...
> clocks = < GCC_SDCC1_AHB_CLK>,
> < GCC_SDCC1_APPS_CLK>,
> <_board>;
> clock-names = "iface", "core", "xo";
> ...
> };
>
> Due to that "xo" fixed clock we get:
>
> MMC: clk_set_rate(clk=ffaf7348, rate=1920)
> Unknown clock id 0
> clk_set_rate(clk=ffaf7598, rate=1920)
> Unknown clock id 0
> clk_set_rate(clk=ffb08868, rate=40)
> mmc@7804000: 0
Does MMC work? This doesn't look like a probe failure to me.
But yes this does look odd, somehow qcs404_clk_set_rate() is being
called with clk->id == 0. The xo_board clock uses a different driver so
it can't be that...
Could you try and add some more logging around here? I can't see what
might be causing this.
>
> -Sumit
>
>>
>> Reviewed-by: Neil Armstrong
>> Signed-off-by: Caleb Connolly
>> ---
>> drivers/mmc/msm_sdhci.c | 69
>> -
>> 1 file changed, 46 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
>> index 604f9c3ff99c..863e6007a905 100644
>> --- a/drivers/mmc/msm_sdhci.c
>> +++ b/drivers/mmc/msm_sdhci.c
>> @@ -44,6 +44,7 @@ struct msm_sdhc_plat {
>> struct msm_sdhc {
>> struct sdhci_host host;
>> void *base;
>> + struct clk_bulk clks;
>> };
>>
>> struct msm_sdhc_variant_info {
>> @@ -54,36 +55,56 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>> static int msm_sdc_clk_init(struct udevice *dev)
>> {
>> - int node = dev_of_offset(dev);
>> - uint clk_rate = fdtdec_get_uint(gd->fdt_blob, node,
>> "clock-frequency",
>> - 40);
>> - uint clkd[2]; /* clk_id and clk_no */
>> - int clk_offset;
>> - struct udevice *clk_dev;
>> - struct clk clk;
>> - int ret;
>> + struct msm_sdhc *prv = dev_get_priv(dev);
>> + ofnode node = dev_ofnode(dev);
>> + uint clk_rate;
>> + int ret, i = 0, n_clks;
>> + const char *clk_name;
>>
>> - ret = fdtdec_get_int_array(gd->fdt_blob, node, "clock", clkd, 2);
>> + ret = ofnode_read_u32(node, "clock-frequency", _rate);
>> if (ret)
>> - return ret;
>> + clk_rate = 40;
>>
>> - clk_offset = fdt_node_offset_by_phandle(gd->fdt_blob, clkd[0]);
>> - if (clk_offset < 0)
>> - return clk_offset;
>> -
>> - ret = uclass_get_device_by_of_offset(UCLASS_CLK, clk_offset,
>> _dev);
>> - if (ret)
>> + ret = clk_get_bulk(dev, >clks);
>> + if (ret) {
>> + debug("Couldn't get mmc clocks: %d\n", ret);
>> return ret;
>> + }
>>
>> - clk.id = clkd[1];
>> - ret = clk_request(clk_dev, );
>> - if (ret < 0)
>> + ret = clk_enable_bulk(>clks);
>> + if (ret) {
>> + debug("Couldn't enable mmc clocks: %d\n", ret);
>> return ret;
>> + }
>>
>> - ret = clk_set_rate(, clk_rate);
>> - clk_free();
>> - if (ret < 0)
>> - return ret;
>> + /* If clock-names is unspecified, then the first clock is the core
>> clock */
>> + if (!ofnode_get_property(node, "clock-names", _clks)) {
>> + if (!clk_set_rate(>clks.clks[0], clk_rate)) {
>> + printf("Couldn't set core clock rate: %d\n", ret);
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + /* Find the index of the "core" clock */
>> + while (i < n_clks) {
>> + ofnode_read_string_index(node, "clock-names", i, _name);
>> + if (!strcmp(clk_name, "core"))
>> + break;
>> + i++;
>> + }
>> +
>> + if (i >= prv->clks.count) {
>> + printf("Couldn't find core clock (index %d but only have %d
>> clocks)\n", i,
>> + prv->clks.count);
>> + return -EINVAL;
>> + }
>> +
>> + /* The clock is already enabled by the clk_bulk above */
>> + ret = clk_set_rate(>clks.clks[i], clk_rate);
>> + if (!ret) {
>> + printf("Couldn't set core clock rate: %d\n", ret);
>> + return -EINVAL;
>> + }
>>
>> return 0;
>> }
>> @@ -188,6 +209,8 @@ static int msm_sdc_remove(struct udevice *dev)
>> if (!var_info->mci_removed)
>> writel(0, priv->base + SDCC_MCI_HC_MODE);
>>
>> + clk_release_bulk(>clks);
>> +
>>
Re: [PATCH v3 3/3] cmd: rng: Add rng list command
Reviewed-by: Igor Opaniuk
On Wed, Jan 31, 2024 at 3:15 PM Weizhao Ouyang wrote:
>
> The 'rng list' command probes all RNG devices and list those devices
> that are successfully probed. Also update the help info.
>
> Reviewed-by: Heinrich Schuchardt
> Signed-off-by: Weizhao Ouyang
> ---
> cmd/rng.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/rng.c b/cmd/rng.c
> index 52f722c7af..b073a6c849 100644
> --- a/cmd/rng.c
> +++ b/cmd/rng.c
> @@ -19,6 +19,22 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> struct udevice *dev;
> int ret = CMD_RET_SUCCESS;
>
> + if (argc == 2 && !strcmp(argv[1], "list")) {
> + int idx = 0;
> +
> + uclass_foreach_dev_probe(UCLASS_RNG, dev) {
> + idx++;
> + printf("RNG #%d - %s\n", dev->seq_, dev->name);
> + }
> +
> + if (!idx) {
> + log_err("No RNG device\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + return CMD_RET_SUCCESS;
> + }
> +
> switch (argc) {
> case 1:
> devnum = 0;
> @@ -56,12 +72,9 @@ static int do_rng(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> return ret;
> }
>
> -U_BOOT_LONGHELP(rng,
> - "[dev [n]]\n"
> - " - print n random bytes(max 64) read from dev\n");
> -
> U_BOOT_CMD(
> rng, 3, 0, do_rng,
> "print bytes from the hardware random number generator",
> - rng_help_text
> + "list - list all the probed rng devices\n"
> + "rng [dev] [n]- print n random bytes(max 64) read from dev\n"
> );
> --
> 2.39.2
>
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Senior Software Engineer, Embedded & Security
E: igor.opan...@foundries.io
W: www.foundries.io
[GIT PULL] Please pull u-boot-amlogic-fixes-20240201
Hi Tom, Please pull this simple fix avoiding printing the board model twice. Thanks, Neil The following changes since commit 6faba41927bdc8973b59678649ef83c564cc421e: Prepare v2024.04-rc1 (2024-01-29 20:53:19 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-fixes-20240201 for you to fetch changes up to 076529725f16f07a5cb2d5feba25d62b5f5a5872: ARM: meson: stop printing board model after sysinfo update (2024-01-30 09:35:51 +0100) - stop printing board model twice after sysinfo update Neil Armstrong (1): ARM: meson: stop printing board model after sysinfo update arch/arm/mach-meson/board-info.c | 10 -- 1 file changed, 10 deletions(-)
Re: [PATCH 1/5] usb: dwc3-generic: implement Qualcomm wrapper
On 01/02/2024 09:34, Mattijs Korpershoek wrote:
> Hi Caleb,
>
> Thank you for the patch.
>
> On mer., janv. 31, 2024 at 14:57, Caleb Connolly
> wrote:
>
>> The Qualcomm specific dwc3 wrapper isn't hugely complicated, implemented
>> the missing initialisation for host and gadget mode.
>>
>> Signed-off-by: Caleb Connolly
>> ---
>> drivers/usb/dwc3/dwc3-generic.c | 99
>> -
>> 1 file changed, 98 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-generic.c
>> b/drivers/usb/dwc3/dwc3-generic.c
>> index 48da621ba966..1119cdecd26d 100644
>> --- a/drivers/usb/dwc3/dwc3-generic.c
>> +++ b/drivers/usb/dwc3/dwc3-generic.c
>> @@ -419,6 +419,99 @@ struct dwc3_glue_ops ti_ops = {
>> .glue_configure = dwc3_ti_glue_configure,
>> };
>>
>> +/* USB QSCRATCH Hardware registers */
>> +#define QSCRATCH_HS_PHY_CTRL 0x10
>> +#define UTMI_OTG_VBUS_VALID BIT(20)
>> +#define SW_SESSVLD_SEL BIT(28)
>> +
>> +#define QSCRATCH_SS_PHY_CTRL 0x30
>> +#define LANE0_PWR_PRESENT BIT(24)
>> +
>> +#define QSCRATCH_GENERAL_CFG 0x08
>> +#define PIPE_UTMI_CLK_SEL BIT(0)
>> +#define PIPE3_PHYSTATUS_SW BIT(3)
>> +#define PIPE_UTMI_CLK_DIS BIT(8)
>> +
>> +#define PWR_EVNT_IRQ_STAT_REG 0x58
>> +#define PWR_EVNT_LPM_IN_L2_MASK BIT(4)
>> +#define PWR_EVNT_LPM_OUT_L2_MASK BIT(5)
>> +
>> +#define SDM845_QSCRATCH_BASE_OFFSET 0xf8800
>> +#define SDM845_QSCRATCH_SIZE 0x400
>> +#define SDM845_DWC3_CORE_SIZE 0xcd00
>> +static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32
>> val)
>> +{
>> +u32 reg;
>> +
>> +reg = readl(base + offset);
>> +reg |= val;
>> +writel(reg, base + offset);
>
> Why can't we use the setbits() macro here?
> see: arch/arm/include/asm/io.h
setbits doesn't give us the same cache coherency guarantees I think(?)
the readl/writel macros include wmb() calls.
That said, I won't pretend to really know what I'm talking about here,
possible setbits() would be suitable, do you have any idea?
>
>> +
>> +/* ensure that above write is through */
>> +readl(base + offset);
>> +}
>> +
>> +static inline void dwc3_qcom_clrbits(void __iomem *base, u32 offset, u32
>> val)
>> +{
>> +u32 reg;
>> +
>> +reg = readl(base + offset);
>> +reg &= ~val;
>> +writel(reg, base + offset);
>
> Same question for clrbits()
>
>> +
>> +/* ensure that above write is through */
>> +readl(base + offset);
>> +}
>> +
[snip]
>> +if (device_is_compatible(dev, "qcom,dwc3")) {
>> +reset_assert_bulk(>resets);
>
> Any reason for not doing error handling on reset_assert_bulk() like it's
> done below ?
Well, the Qualcomm reset driver will never return an error, and if it
did, the assert failing (presumably because it's already asserted) is
not necessarily an error we'd need to care about - it's only an error if
we can't deassert the reset.
So I think this is fine.
>
>> +udelay(500);
>> +}
>> ret = reset_deassert_bulk(>resets);
>> if (ret) {
>> reset_release_bulk(>resets);
>> @@ -623,7 +720,7 @@ static const struct udevice_id dwc3_glue_ids[] = {
>> { .compatible = "rockchip,rk3399-dwc3" },
>> { .compatible = "rockchip,rk3568-dwc3", .data = (ulong)_ops },
>> { .compatible = "rockchip,rk3588-dwc3", .data = (ulong)_ops },
>> -{ .compatible = "qcom,dwc3" },
>> +{ .compatible = "qcom,dwc3", .data = (ulong)_ops },
>> { .compatible = "fsl,imx8mp-dwc3", .data = (ulong)_ops },
>> { .compatible = "fsl,imx8mq-dwc3" },
>> { .compatible = "intel,tangier-dwc3" },
>>
>> --
>> 2.43.0
--
// Caleb (they/them)
[PATCH v2 1/3] mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled
From: Yang Xiwen
This can avoid hardcoding a clock rate in driver. Also can enable the
clocks and deassert the resets if the pre-bootloader does not do this
for us.
Currently only enabled for Hi3798MV200.
Signed-off-by: Yang Xiwen
---
drivers/mmc/hi6220_dw_mmc.c | 61 -
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
index 71962cd47e..a4b8072976 100644
--- a/drivers/mmc/hi6220_dw_mmc.c
+++ b/drivers/mmc/hi6220_dw_mmc.c
@@ -5,15 +5,24 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
+enum hi6220_dwmmc_clk_type {
+ HI6220_DWMMC_CLK_BIU,
+ HI6220_DWMMC_CLK_CIU,
+ HI6220_DWMMC_CLK_CNT,
+};
+
struct hi6220_dwmmc_plat {
struct mmc_config cfg;
struct mmc mmc;
@@ -21,6 +30,8 @@ struct hi6220_dwmmc_plat {
struct hi6220_dwmmc_priv_data {
struct dwmci_host host;
+ struct clk *clks[HI6220_DWMMC_CLK_CNT];
+ struct reset_ctl_bulk rsts;
};
struct hisi_mmc_data {
@@ -32,7 +43,29 @@ static int hi6220_dwmmc_of_to_plat(struct udevice *dev)
{
struct hi6220_dwmmc_priv_data *priv = dev_get_priv(dev);
struct dwmci_host *host = >host;
+ int ret;
+ if (CONFIG_IS_ENABLED(CLK) && CONFIG_IS_ENABLED(DM_RESET)) {
+ priv->clks[HI6220_DWMMC_CLK_BIU] = devm_clk_get(dev, "biu");
+ if (IS_ERR(priv->clks[HI6220_DWMMC_CLK_BIU])) {
+ ret = PTR_ERR(priv->clks[HI6220_DWMMC_CLK_BIU]);
+ dev_err(dev, "Failed to get BIU clock(ret = %d).\n",
ret);
+ return log_msg_ret("clk", ret);
+ }
+
+ priv->clks[HI6220_DWMMC_CLK_CIU] = devm_clk_get(dev, "ciu");
+ if (IS_ERR(priv->clks[HI6220_DWMMC_CLK_CIU])) {
+ ret = PTR_ERR(priv->clks[HI6220_DWMMC_CLK_CIU]);
+ dev_err(dev, "Failed to get CIU clock(ret = %d).\n",
ret);
+ return log_msg_ret("clk", ret);
+ }
+
+ ret = reset_get_bulk(dev, >rsts);
+ if (ret) {
+ dev_err(dev, "Failed to get resets(ret = %d)", ret);
+ return log_msg_ret("rst", ret);
+ }
+ }
host->name = dev->name;
host->ioaddr = dev_read_addr_ptr(dev);
host->buswidth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
@@ -56,11 +89,37 @@ static int hi6220_dwmmc_probe(struct udevice *dev)
struct hi6220_dwmmc_priv_data *priv = dev_get_priv(dev);
struct dwmci_host *host = >host;
struct hisi_mmc_data *mmc_data;
+ int ret;
mmc_data = (struct hisi_mmc_data *)dev_get_driver_data(dev);
- /* Use default bus speed due to absence of clk driver */
host->bus_hz = mmc_data->clock;
+ if (CONFIG_IS_ENABLED(CLK) && CONFIG_IS_ENABLED(DM_RESET)) {
+ ret = clk_prepare_enable(priv->clks[HI6220_DWMMC_CLK_BIU]);
+ if (ret) {
+ dev_err(dev, "Failed to enable biu clock(ret = %d).\n",
ret);
+ return log_msg_ret("clk", ret);
+ }
+
+ ret = clk_prepare_enable(priv->clks[HI6220_DWMMC_CLK_CIU]);
+ if (ret) {
+ dev_err(dev, "Failed to enable ciu clock(ret = %d).\n",
ret);
+ return log_msg_ret("clk", ret);
+ }
+
+ ret = reset_deassert_bulk(>rsts);
+ if (ret) {
+ dev_err(dev, "Failed to deassert resets(ret = %d).\n",
ret);
+ return log_msg_ret("rst", ret);
+ }
+
+ host->bus_hz = clk_get_rate(priv->clks[HI6220_DWMMC_CLK_CIU]);
+ if (host->bus_hz <= 0) {
+ dev_err(dev, "Failed to get ciu clock rate(ret =
%d).\n", ret);
+ return log_msg_ret("clk", ret);
+ }
+ }
+ dev_dbg(dev, "bus clock rate: %d.\n", host->bus_hz);
dwmci_setup_cfg(>cfg, host, host->bus_hz, 40);
host->mmc = >mmc;
--
2.43.0
[PATCH v2 3/3] mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe
From: Yang Xiwen
The value defaults to 0 and is ignored by dw_mmc code, so the other
users are not affected.
Setting this explicitly fixes some weird reading error found on Hi3798MV200.
Fixes: 8a5dc8140e62 ("mmc: hi6220_dw_mmc: add compatible for HC2910 support")
Signed-off-by: Yang Xiwen
---
drivers/mmc/hi6220_dw_mmc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
index a4b8072976..dc0210402b 100644
--- a/drivers/mmc/hi6220_dw_mmc.c
+++ b/drivers/mmc/hi6220_dw_mmc.c
@@ -37,6 +37,7 @@ struct hi6220_dwmmc_priv_data {
struct hisi_mmc_data {
unsigned int clock;
bool use_fifo;
+ u32 fifoth_val;
};
static int hi6220_dwmmc_of_to_plat(struct udevice *dev)
@@ -125,6 +126,7 @@ static int hi6220_dwmmc_probe(struct udevice *dev)
host->mmc = >mmc;
host->fifo_mode = mmc_data->use_fifo;
+ host->fifoth_val = mmc_data->fifoth_val;
host->mmc->priv = >host;
upriv->mmc = host->mmc;
host->mmc->dev = dev;
@@ -154,13 +156,20 @@ static const struct hisi_mmc_data hi6220_mmc_data = {
.use_fifo = false,
};
+static const struct hisi_mmc_data hi3798mv2x_mmc_data = {
+ .clock = 5000,
+ .use_fifo = false,
+ // FIFO depth is 256
+ .fifoth_val = MSIZE(4) | RX_WMARK(0x7f) | TX_WMARK(0x80),
+};
+
static const struct udevice_id hi6220_dwmmc_ids[] = {
{ .compatible = "hisilicon,hi6220-dw-mshc",
.data = (ulong)_mmc_data },
{ .compatible = "hisilicon,hi3798cv200-dw-mshc",
.data = (ulong)_mmc_data },
{ .compatible = "hisilicon,hi3798mv200-dw-mshc",
- .data = (ulong)_mmc_data },
+ .data = (ulong)_mmc_data },
{ .compatible = "hisilicon,hi3660-dw-mshc",
.data = (ulong)_mmc_data },
{ }
--
2.43.0
[PATCH v2 2/3] mmc: dw_mmc: Don't return error if data busy timeout
From: Yang Xiwen
As described in [1], some poor hardware or cards would fail to release
the bus and keep driving data lines low. Ignore it and send the next cmd
directly seems okay for most cases.
[1]:
https://patchwork.kernel.org/project/linux-mmc/patch/1424458179-5456-1-git-send-email-diand...@chromium.org/
Signed-off-by: Yang Xiwen
---
drivers/mmc/dw_mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 400066fa99..e103664145 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -262,8 +262,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
if (get_timer(start) > timeout) {
- debug("%s: Timeout on data busy\n", __func__);
- return -ETIMEDOUT;
+ debug("%s: Timeout on data busy, continue anyway\n",
__func__);
+ break;
}
}
--
2.43.0
[PATCH v2 0/3] mmc: hi6220-dwmmc: handle resets and clocks
Also allow setup fifoth_val in driver Signed-off-by: Yang Xiwen --- Changes in v2: - dw-mmc: proceed if data busy found - hi6220-dw-mmc: add fifoth_val setup, separate hi3798mv200 data - Link to v1: https://lore.kernel.org/r/20240119-mmc-v1-1-aee6b2cf6...@outlook.com --- Yang Xiwen (3): mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled mmc: dw_mmc: Don't return error if data busy timeout mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe drivers/mmc/dw_mmc.c| 4 +-- drivers/mmc/hi6220_dw_mmc.c | 72 +++-- 2 files changed, 72 insertions(+), 4 deletions(-) --- base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3 change-id: 20240119-mmc-9cf7f3455cb4 Best regards, -- Yang Xiwen
Re: [RFC PATCH v2 2/2] board: ad401: example of fastboot oem board realization
On Thu, Feb 01, 2024 at 12:20:27PM +0300, Alexey Romanov wrote:
> +static int fastboot_nand_write_tpl(struct mtd_info *mtd, void *buffer,
> +u32 offset, size_t size, int flags)
> +{
> + int boot_cpy_num = meson_bootloader_copy_num(BOOT_TPL);
> + u64 size_per_copy = meson_bootloader_copy_size(mtd, BOOT_TPL);
> + int i;
> +
> + for (i = 0; i < boot_cpy_num; i++) {
> + size_t retlen, len = size;
> + int ret;
> +
> + ret = nand_write_skip_bad(mtd, offset + (i * size_per_copy),
> + , , offset + size_per_copy,
^^
Sorry if I'm missing something obvious, but why is the limit
"offset + size_per_copy"? I would have expected it to be just
"size_per_copy" or maybe some kind of limit minus the offset...
> + buffer, flags);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
regards,
dan carpenter
Re: [PATCH 5/5] iommu: qcom-smmu: fix debugging
Hi Caleb,
Thank you for the patch.
On mer., janv. 31, 2024 at 14:57, Caleb Connolly
wrote:
> The priv struct was wrong in dump_boot_mappings(). Causing errors when
> compiling with -DDEBUG. Fix this.
>
> Signed-off-by: Caleb Connolly
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/iommu/qcom-hyp-smmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/qcom-hyp-smmu.c b/drivers/iommu/qcom-hyp-smmu.c
> index 8e5cdb581550..f2b39de56f4a 100644
> --- a/drivers/iommu/qcom-hyp-smmu.c
> +++ b/drivers/iommu/qcom-hyp-smmu.c
> @@ -319,7 +319,7 @@ static int qcom_smmu_connect(struct udevice *dev)
> }
>
> #ifdef DEBUG
> -static inline void dump_boot_mappings(struct arm_smmu_priv *priv)
> +static inline void dump_boot_mappings(struct qcom_smmu_priv *priv)
> {
> u32 val;
> int i;
>
> --
> 2.43.0
Re: [PATCH 4/5] usb: gadget: UMS: support multiple sector sizes
Hi Caleb,
Thank you for the patch.
On mer., janv. 31, 2024 at 14:57, Caleb Connolly
wrote:
> UFS storage often uses a 4096-byte sector size, add support for dynamic
> sector sizes based loosely on the Linux implementation.
>
> Signed-off-by: Caleb Connolly
Reviewed-by: Mattijs Korpershoek
> ---
> cmd/usb_mass_storage.c | 4 --
> drivers/usb/gadget/f_mass_storage.c | 101
>
> drivers/usb/gadget/storage_common.c | 12 +++--
> include/usb_mass_storage.h | 1 -
> 4 files changed, 65 insertions(+), 53 deletions(-)
>
> diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
> index a8ddeb494628..751701fe73af 100644
> --- a/cmd/usb_mass_storage.c
> +++ b/cmd/usb_mass_storage.c
> @@ -88,10 +88,6 @@ static int ums_init(const char *devtype, const char
> *devnums_part_str)
> if (!strchr(devnum_part_str, ':'))
> partnum = 0;
>
> - /* f_mass_storage.c assumes SECTOR_SIZE sectors */
> - if (block_dev->blksz != SECTOR_SIZE)
> - goto cleanup;
> -
> ums_new = realloc(ums, (ums_count + 1) * sizeof(*ums));
> if (!ums_new)
> goto cleanup;
> diff --git a/drivers/usb/gadget/f_mass_storage.c
> b/drivers/usb/gadget/f_mass_storage.c
> index c725aed3f626..d880928044f4 100644
> --- a/drivers/usb/gadget/f_mass_storage.c
> +++ b/drivers/usb/gadget/f_mass_storage.c
> @@ -724,12 +724,13 @@ static int do_read(struct fsg_common *common)
> curlun->sense_data = SS_LOGICAL_BLOCK_ADDRESS_OUT_OF_RANGE;
> return -EINVAL;
> }
> - file_offset = ((loff_t) lba) << 9;
> + file_offset = ((loff_t)lba) << curlun->blkbits;
>
> /* Carry out the file reads */
> amount_left = common->data_size_from_cmnd;
> - if (unlikely(amount_left == 0))
> + if (unlikely(amount_left == 0)) {
> return -EIO;/* No default reply */
> + }
>
> for (;;) {
>
> @@ -768,13 +769,13 @@ static int do_read(struct fsg_common *common)
>
> /* Perform the read */
> rc = ums[common->lun].read_sector([common->lun],
> - file_offset / SECTOR_SIZE,
> - amount / SECTOR_SIZE,
> + file_offset / curlun->blksize,
> + amount / curlun->blksize,
> (char __user *)bh->buf);
> if (!rc)
> return -EIO;
>
> - nread = rc * SECTOR_SIZE;
> + nread = rc * curlun->blksize;
>
> VLDBG(curlun, "file read %u @ %llu -> %d\n", amount,
> (unsigned long long) file_offset,
> @@ -787,7 +788,7 @@ static int do_read(struct fsg_common *common)
> } else if (nread < amount) {
> LDBG(curlun, "partial file read: %d/%u\n",
> (int) nread, amount);
> - nread -= (nread & 511); /* Round down to a block */
> + nread -= (nread & (curlun->blksize - 1)); /*
> Round down to a block */
> }
> file_offset += nread;
> amount_left -= nread;
> @@ -861,7 +862,7 @@ static int do_write(struct fsg_common *common)
>
> /* Carry out the file writes */
> get_some_more = 1;
> - file_offset = usb_offset = ((loff_t) lba) << 9;
> + file_offset = usb_offset = ((loff_t)lba) << curlun->blkbits;
> amount_left_to_req = common->data_size_from_cmnd;
> amount_left_to_write = common->data_size_from_cmnd;
>
> @@ -893,7 +894,7 @@ static int do_write(struct fsg_common *common)
> curlun->info_valid = 1;
> continue;
> }
> - amount -= (amount & 511);
> + amount -= (amount & (curlun->blksize - 1));
> if (amount == 0) {
>
> /* Why were we were asked to transfer a
> @@ -942,12 +943,12 @@ static int do_write(struct fsg_common *common)
>
> /* Perform the write */
> rc = ums[common->lun].write_sector([common->lun],
> -file_offset / SECTOR_SIZE,
> -amount / SECTOR_SIZE,
> +file_offset / curlun->blksize,
> +amount / curlun->blksize,
> (char __user *)bh->buf);
> if (!rc)
> return -EIO;
> - nwritten = rc * SECTOR_SIZE;
> + nwritten = rc * curlun->blksize;
>
> VLDBG(curlun, "file write %u @ %llu -> %d\n", amount,
>
Re: [PATCH 3/5] usb: gadget: CDC ACM: call usb_gadget_initialize
Hi Caleb,
Thank you for the patch.
On mer., janv. 31, 2024 at 14:57, Caleb Connolly
wrote:
> To actually use the gadget the peripheral driver must be probed and we
> must call g_dnl_clear_detach(). Otherwise acm_stdio_start() will always
> fail to find a UDC on DT platforms.
>
> Signed-off-by: Caleb Connolly
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/usb/gadget/f_acm.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c
> index de42e0189e8d..ba216128ab27 100644
> --- a/drivers/usb/gadget/f_acm.c
> +++ b/drivers/usb/gadget/f_acm.c
> @@ -623,12 +623,21 @@ static void acm_stdio_puts(struct stdio_dev *dev, const
> char *str)
>
> static int acm_stdio_start(struct stdio_dev *dev)
> {
> + struct udevice *udc;
> int ret;
>
> if (dev->priv) { /* function already exist */
> return 0;
> }
>
> + ret = udc_device_get_by_index(0, );
> + if (ret) {
> + pr_err("USB init failed: %d\n", ret);
> + return ret;
> + }
> +
> + g_dnl_clear_detach();
> +
> ret = g_dnl_register("usb_serial_acm");
> if (ret)
> return ret;
>
> --
> 2.43.0
[PATCH 1/1] sunxi: sun4i: Introduce KConfig option SPL_SYS_CLK_FREQ
This option can be used to modify the initial SPL
CPU clock frequency.
This follows an earlier discussion regarding A20
CPUs dying after reboot in SPL initialization due to
incompatible CPU clock frequency and core voltage. [1]
First attempt was to update PLL1_CFG_DEFAULT to a fixed
lower frequency (144MHz), which fixed the observed issue
but might not suit all A20 users. A KConfig option
should be the better solution.
[1]
https://lists.denx.de/pipermail/u-boot/2024-January/544897.html
Signed-off-by: Ludwig Kormann
---
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 4
arch/arm/mach-sunxi/Kconfig | 8
arch/arm/mach-sunxi/clock_sun4i.c | 11 ++-
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 2cec91cb20..11b350824e 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -134,12 +134,16 @@ struct sunxi_ccm_reg {
#define CCM_PLL1_CFG_PLL4_EXCH_SHIFT 25
#define CCM_PLL1_CFG_BIAS_CUR_SHIFT20
#define CCM_PLL1_CFG_DIVP_SHIFT16
+#define CCM_PLL1_CFG_DIVP_MASK (0x3 << CCM_PLL1_CFG_DIVP_SHIFT)
#define CCM_PLL1_CFG_LCK_TMR_SHIFT 13
#define CCM_PLL1_CFG_FACTOR_N_SHIFT8
+#define CCM_PLL1_CFG_FACTOR_N_MASK (0x1f <<
CCM_PLL1_CFG_FACTOR_N_SHIFT)
#define CCM_PLL1_CFG_FACTOR_K_SHIFT4
+#define CCM_PLL1_CFG_FACTOR_K_MASK (0x3 <<
CCM_PLL1_CFG_FACTOR_K_SHIFT)
#define CCM_PLL1_CFG_SIG_DELT_PAT_IN_SHIFT 3
#define CCM_PLL1_CFG_SIG_DELT_PAT_EN_SHIFT 2
#define CCM_PLL1_CFG_FACTOR_M_SHIFT0
+#define CCM_PLL1_CFG_FACTOR_M_MASK (0x3 <<
CCM_PLL1_CFG_FACTOR_M_SHIFT)
#define PLL1_CFG_DEFAULT 0xa1005000
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index fe89aec6b9..85e3a26855 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -705,6 +705,14 @@ config SYS_CLK_FREQ
default 100800 if MACH_SUN50I_H616
default 100800 if MACH_SUN8I_R528
+if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+config SPL_SYS_CLK_FREQ
+ int "sunxi SPL CPU clock frequency"
+ default 384
+ ---help---
+ A static value for the sunxi SPL CPU frequency, must be a multiple of 24.
+endif
+
config SYS_CONFIG_NAME
default "suniv" if MACH_SUNIV
default "sun4i" if MACH_SUN4I
diff --git a/arch/arm/mach-sunxi/clock_sun4i.c
b/arch/arm/mach-sunxi/clock_sun4i.c
index 8f1d1b65f0..04623c1d09 100644
--- a/arch/arm/mach-sunxi/clock_sun4i.c
+++ b/arch/arm/mach-sunxi/clock_sun4i.c
@@ -25,7 +25,16 @@ void clock_init_safe(void)
APB0_DIV_1 << APB0_DIV_SHIFT |
CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
>cpu_ahb_apb0_cfg);
- writel(PLL1_CFG_DEFAULT, >pll1_cfg);
+ writel((PLL1_CFG_DEFAULT &
+ ~(CCM_PLL1_CFG_FACTOR_N_MASK |
+ CCM_PLL1_CFG_FACTOR_K_MASK |
+ CCM_PLL1_CFG_FACTOR_M_MASK |
+ CCM_PLL1_CFG_DIVP_MASK)) |
+ (CONFIG_SPL_SYS_CLK_FREQ / 24) << CCM_PLL1_CFG_FACTOR_N_SHIFT |
+ 0 << CCM_PLL1_CFG_FACTOR_K_SHIFT |
+ 0 << CCM_PLL1_CFG_FACTOR_M_SHIFT |
+ 0 << CCM_PLL1_CFG_DIVP_SHIFT,
+ >pll1_cfg);
sdelay(200);
writel(AXI_DIV_1 << AXI_DIV_SHIFT |
AHB_DIV_2 << AHB_DIV_SHIFT |
--
2.39.2
Re: [PATCH 2/5] usb: dwc3: select DM_USB_GADGET
Hi Caleb, Thank you for the patch. On mer., janv. 31, 2024 at 14:57, Caleb Connolly wrote: > DWC3 platforms depend on DM_USB_GADGET for gadget drivers to work, > otherwise compilation fails due to no implementation of > dm_usb_gadget_handle_interrupts(). > > Signed-off-by: Caleb Connolly Reviewed-by: Mattijs Korpershoek > --- > drivers/usb/dwc3/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index c0c8c16fd9c2..8a70bc682322 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -11,6 +11,7 @@ config USB_DWC3_GADGET > bool "USB Gadget support for DWC3" > default y > depends on USB_GADGET > + select DM_USB_GADGET > select USB_GADGET_DUALSPEED > > comment "Platform Glue Driver Support" > > -- > 2.43.0
[PATCH 2/3] test: phy: test generic_setup(shutdown)_phy_bulk()
From: Yang Xiwen add unittests for the newly introduced helper functions. Signed-off-by: Yang Xiwen --- test/dm/phy.c | 4 1 file changed, 4 insertions(+) diff --git a/test/dm/phy.c b/test/dm/phy.c index 0cf3689fde..cb16844a0a 100644 --- a/test/dm/phy.c +++ b/test/dm/phy.c @@ -159,6 +159,8 @@ static int dm_test_phy_bulk(struct unit_test_state *uts) ut_asserteq(0, generic_phy_power_on_bulk()); ut_asserteq(0, generic_phy_power_off_bulk()); ut_asserteq(0, generic_phy_exit_bulk()); + ut_asserteq(0, generic_setup_phy_bulk(parent, )); + ut_asserteq(0, generic_shutdown_phy_bulk()); /* has a known problem phy */ ut_assertok(uclass_get_device_by_name(UCLASS_SIMPLE_BUS, @@ -171,6 +173,8 @@ static int dm_test_phy_bulk(struct unit_test_state *uts) ut_asserteq(-EIO, generic_phy_power_on_bulk()); ut_asserteq(-EIO, generic_phy_power_off_bulk()); ut_asserteq(0, generic_phy_exit_bulk()); + ut_asserteq(-EIO, generic_setup_phy_bulk(parent, )); + ut_asserteq(-EIO, generic_shutdown_phy_bulk()); return 0; } -- 2.43.0
[PATCH 3/3] usb: ehci: Make usage of generic_{setup,shutdown}_phy_bulk() helpers
From: Yang Xiwen
Replace generic_setup_phy() and generic_shutdown_phy() by respectively
generic_setup_phy_bulk() and generic_shutdown_phy_bulk().
Signed-off-by: Yang Xiwen
---
drivers/usb/host/ehci-generic.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index 936e30438d..e109d84d73 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -25,7 +25,7 @@ struct generic_ehci {
struct ehci_ctrl ctrl;
struct clk_bulk clocks;
struct reset_ctl_bulk resets;
- struct phy phy;
+ struct phy_bulk phys;
struct udevice *vbus_supply;
};
@@ -95,7 +95,7 @@ static int ehci_usb_probe(struct udevice *dev)
if (err)
goto reset_err;
- err = generic_setup_phy(dev, >phy, 0);
+ err = generic_setup_phy_bulk(dev, >phys);
if (err)
goto regulator_err;
@@ -110,7 +110,7 @@ static int ehci_usb_probe(struct udevice *dev)
return 0;
phy_err:
- ret = generic_shutdown_phy(>phy);
+ ret = generic_shutdown_phy_bulk(>phys);
if (ret)
dev_err(dev, "failed to shutdown usb phy (ret=%d)\n", ret);
@@ -140,7 +140,7 @@ static int ehci_usb_remove(struct udevice *dev)
if (ret)
return ret;
- ret = generic_shutdown_phy(>phy);
+ ret = generic_shutdown_phy_bulk(>phys);
if (ret)
return ret;
--
2.43.0
[PATCH 1/3] phy: add generic_setup(shutdown)_phy_bulk()
From: Yang Xiwen
They are the bulk version of generic_setup(shutdown)_phy().
Signed-off-by: Yang Xiwen
---
drivers/phy/phy-uclass.c | 33 +
include/generic-phy.h| 29 +
2 files changed, 62 insertions(+)
diff --git a/drivers/phy/phy-uclass.c b/drivers/phy/phy-uclass.c
index 0dcfe258bc..d50ebbe3a0 100644
--- a/drivers/phy/phy-uclass.c
+++ b/drivers/phy/phy-uclass.c
@@ -528,6 +528,28 @@ int generic_setup_phy(struct udevice *dev, struct phy
*phy, int index)
return ret;
}
+int generic_setup_phy_bulk(struct udevice *dev, struct phy_bulk *bulk)
+{
+ struct phy *phys = bulk->phys;
+ int i, ret;
+
+ for (i = 0; i < bulk->count; i++) {
+ ret = generic_setup_phy(dev, [i], i);
+ if (ret) {
+ pr_err("Can't setup PHY%d\n", i);
+ goto phys_setup_err;
+ }
+ }
+
+ return 0;
+
+phys_setup_err:
+ for (; i > 0; i--)
+ generic_shutdown_phy([i - 1]);
+
+ return ret;
+}
+
int generic_shutdown_phy(struct phy *phy)
{
int ret;
@@ -542,6 +564,17 @@ int generic_shutdown_phy(struct phy *phy)
return generic_phy_exit(phy);
}
+int generic_shutdown_phy_bulk(struct phy_bulk *bulk)
+{
+ struct phy *phys = bulk->phys;
+ int i, ret = 0;
+
+ for (i = 0; i < bulk->count; i++)
+ ret |= generic_shutdown_phy([i]);
+
+ return ret;
+}
+
UCLASS_DRIVER(phy) = {
.id = UCLASS_PHY,
.name = "phy",
diff --git a/include/generic-phy.h b/include/generic-phy.h
index eaab749166..2d1bf7c1ea 100644
--- a/include/generic-phy.h
+++ b/include/generic-phy.h
@@ -420,6 +420,16 @@ int generic_phy_power_off_bulk(struct phy_bulk *bulk);
*/
int generic_setup_phy(struct udevice *dev, struct phy *phy, int index);
+/**
+ * generic_setup_phy() - Get, initialize and power on all phys in a phy bulk.
+ *
+ * @dev: The consumer device.
+ * @bulk: A pointer to the PHY bulk
+ *
+ * Return: 0 if OK, or negative error code.
+ */
+int generic_setup_phy_bulk(struct udevice *dev, struct phy_bulk *bulk);
+
/**
* generic_shutdown_phy() - Power off and de-initialize phy.
*
@@ -429,6 +439,15 @@ int generic_setup_phy(struct udevice *dev, struct phy
*phy, int index);
*/
int generic_shutdown_phy(struct phy *phy);
+/**
+ * generic_shutdown_phy_bulk() - Power off and de-initialize all phys in a phy
bulk.
+ *
+ * @bulk: A pointer to the PHY bulk.
+ *
+ * Return: 0 if OK, or negative error code.
+ */
+int generic_shutdown_phy_bulk(struct phy_bulk *bulk);
+
#else /* CONFIG_PHY */
static inline int generic_phy_init(struct phy *phy)
@@ -514,11 +533,21 @@ static inline int generic_setup_phy(struct udevice *dev,
struct phy *phy, int in
return 0;
}
+static inline int generic_setup_phy_bulk(struct udevice *dev, struct phy_bulk
*bulk)
+{
+ return 0;
+}
+
static inline int generic_shutdown_phy(struct phy *phy)
{
return 0;
}
+static inline int generic_shutdown_phy_bulk(struct phy_bulk *bulk)
+{
+ return 0;
+}
+
#endif /* CONFIG_PHY */
/**
--
2.43.0
[PATCH 0/3] usb: ehci-generic: setup a bulk of phy when possible
one USB controller can have multiple ports specified in dts, all of them
should be setup to make use of all possible ports.
Signed-off-by: Yang Xiwen
---
Yang Xiwen (3):
phy: add generic_setup(shutdown)_phy_bulk()
test: phy: test generic_setup(shutdown)_phy_bulk()
usb: ehci: Make usage of generic_{setup,shutdown}_phy_bulk() helpers
drivers/phy/phy-uclass.c| 33 +
drivers/usb/host/ehci-generic.c | 8
include/generic-phy.h | 29 +
test/dm/phy.c | 4
4 files changed, 70 insertions(+), 4 deletions(-)
---
base-commit: b6d8969bcb94321dfed1399f2eaa8768ba42caaa
change-id: 20240201-ehci-6c3aa7d97932
Best regards,
--
Yang Xiwen
[PATCH v2] qemu-arm: round down memory to multiple of 2MB for LPAE
QEMU's -m option can take fractional megabyte values,
and lowest granularity seems to be 0x2000.
For example, run qemu with amount of memory set to 15k (0x61A9400):
$ qemu-system-arm -machine virt -cpu cortex-a15 -m 15k \
-bios denx/u-boot.bin -nographic
=> fdt addr $fdt_addr
=> fdt print /memory@4000
memory@4000 {
reg = <0x 0x4000 0x 0x061aa000>;
device_type = "memory";
};
When LPAE is enabled, 1:1 mapping is created using 2 MB blocks.
In case amount of memory provided to QEMU is not multiple
of 2 MB, hang occurs during MMU initialization.
How to reproduce:
qemu-system-arm -machine virt -m 1058 -nographic -bios u-boot.bin - boots
qemu-system-arm -machine virt -m 1057 -nographic -bios u-boot.bin - hangs
DRAM: 1 GiB
initcall: 60011df8
initcall: 60011904
New Stack Pointer is: 80fffe90
initcall: 60011a20
initcall: 60011bcc
initcall: 60011bd4
initcall: 600119b4
Relocation Offset is: 22042000
Relocating to 82042000, new gd at 81001ed0, sp at 80fffe90
initcall: 60011b8c
initcall: 82053ea0
initcall: 82053ea8
initcall: 60012040 (relocated to 82054040)
dram_bank_mmu_setup: bank: 0
- hang here during mmu init -
This patches rounds down to the nearest multiple of 2MB when
CONFIG_ARMV7_LPAE=y.
Fixes: 3fa914af82("arm: qemu: implement enable_caches()")
Signed-off-by: Igor Opaniuk
---
Changes in v2:
- Adjust commit message, add more details
board/emulation/qemu-arm/qemu-arm.c | 12
1 file changed, 12 insertions(+)
diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
index 942f1fff571..ecfd19f1a7e 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -127,6 +127,18 @@ int dram_init(void)
if (fdtdec_setup_mem_size_base() != 0)
return -EINVAL;
+ /*
+* When LPAE is enabled (ARMv7),
+* 1:1 mapping is created using 2 MB blocks.
+*
+* In case amount of memory provided to QEMU
+* is not multiple of 2 MB, round down the amount
+* of available memory to avoid hang during MMU
+* initialization.
+*/
+ if (CONFIG_IS_ENABLED(ARMV7_LPAE))
+ gd->ram_size -= (gd->ram_size % 0x20);
+
return 0;
}
--
2.34.1
Re: [PATCH 1/3] rockchip: rk35xx: Remove use of eMMC DDR52 mode
Hi Jonas, On 2/1/24 11:51, Jonas Karlman wrote: Hi Quentin, On 2024-02-01 11:18, Quentin Schulz wrote: Hi Jonas, On 1/27/24 12:15, Jonas Karlman wrote: Hi Eugen, On 2024-01-27 04:48, Eugen Hristev wrote: Hi Jonas, On 1/27/24 01:26, Jonas Karlman wrote: Writing to eMMC using DDR52 mode does not work reliably or at all on RK356x and RK3588 boards. This is related to the old issue I encountered last year with mmc write? Yes, I think it is. I did some testing on RK3566/RK3568/RK3588S/RK3588 boards with different eMMC modules with following result: Read seem to work with all enabled modes: RK3566: MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz) and HS200 (200MHz) RK3568/RK3588S/RK3588: all above + HS400 (200MHz) and HS400ES (200MHz) However, write had issues with some of the modes: MMC DDR52 (52MHz): all RK35xx HS400/HS400ES: only on RK3568 after changing hs400_txclk_tapnum to 8 HS200 seem to be the most stable write speed that worked on all SoCs. So, dropping MMC DDR52 (52MHz) and enable use of HS200 (200MHz) seem to be the best option to get speedy and working read and write eMMC. 1) we have this enabled on RK3588 Jaguar in upstream Linux... I may have improperly tested it then, would you mind sharing how you tested this mode on RK3588 so I can reproduce this and fix it on our product if we're impacted? I assume because we have HS200/HS400/HS400-ES enabled, DDR52 would never be used? (our eMMC is soldered and support the former modes). My main mode of testing eMMC in U-Boot has been to enable following Kconfig options, CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_HS400_ES_SUPPORT=y CONFIG_MMC_SPEED_MODE_SET=y and from U-Boot cli run following, => mmc rescan && mmc info && mmc read 1000 2000 1 => mmc rescan && mmc info && mmc write 2000 4000 1 for each of the modes below. 0 = MMC legacy 1 = MMC High Speed (26MHz) 3 = MMC High Speed (52MHz) 4 = MMC DDR52 (52MHz) 10 = HS200 (200MHz) 11 = HS400 (200MHz) 12 = HS400ES (200MHz) on different boards and different eMMC modules. Using some modes the read or write return ERROR instead of OK. When ERROR was reported a rescan or board reset was needed to test next mode. Please also note that I have only tested in U-Boot, not in linux. Thanks for the tips on how to test these. I have run the following commands on an RK3588 Jaguar (master branch + your v6.8-rc1 DTS sync patch series + Jaguar patch series): => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i in 0 1 3 4 10 11 12; do mmc rescan $i && mmc read 1000 2000 10; if test $? -ne 0; then echo $i FAILED; fi; done; done Which is 20 iterations of an mmc read at each of the 7 supported modes. The result is: 1 fail in HS200, 2 fails in HS400, the rest passes just fine. => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i in 0 1 3 4 10 11 12; do mmc rescan $i && mmc write 2000 4000 10; if test $? -ne 0; then echo $i FAILED; fi; done; done Which is 20 iterations of an mmc write at each of the 7 supported modes. The result is: 20 fails in DDR52, 2 fails in HS200, the rest passes just fine. So it seems DDR52, HS200 and HS400 aren't stable on my board, but HS400ES somehow is (which is enabled in our defconfig). I'll check if there's an easier way to test the Linux kernel than rebooting with a newer DTB between every try. Cheers, Quentin 2) Why are we not enabling HS400/HS400-ES for RK3588 boards? You seem to be saying there are issues with HS400/HS400-ES on RK3568 but you didn't mention the status for RK3588. Did I misunderstand the last sentence? Can you please rephrase in that case? I can see now that my wording was very confusing. Write for HS400/HS400ES mode only worked on RK3568 after modification to the driver, on RK3588 write always returned error for me. So on RK3568 HS400 modes could be made work, on remaining SoCs there was issues. Regards, Jonas Cheers, Quentin
[PATCH 4/5] arm64: zynqmp: Do not expose usbhub nodes on kr260 usb1
usb0 is already updated but forget to also update usb1.
Fixes: 4ff083f09bc2 ("arm64: zynqmp: Do not expose usbhub nodes")
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-sck-kr-g-revA.dtso | 3 ++-
arch/arm/dts/zynqmp-sck-kr-g-revB.dtso | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
b/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
index afcf8a8ee6ba..ce7c5eb6d346 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
@@ -174,12 +174,13 @@
phys = < 3 PHY_TYPE_USB3 1 2>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
assigned-clock-rates = <25000>, <2000>;
-
+#if 0
usbhub1: usb-hub { /* u84 */
i2c-bus = <_i2c1>;
compatible = "microchip,usb5744";
reset-gpios = < 4 GPIO_ACTIVE_LOW>;
};
+#endif
};
_1 {
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
b/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
index 24be5dd84e19..6c29f6574134 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
@@ -175,11 +175,13 @@
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
assigned-clock-rates = <25000>, <2000>;
+#if 0
usbhub1: usb-hub { /* u84 */
i2c-bus = <_i2c1>;
compatible = "microchip,usb5744";
reset-gpios = < 4 GPIO_ACTIVE_LOW>;
};
+#endif
};
_1 {
--
2.36.1
[PATCH 5/5] arm64: zynqmp: Disable DP on kd240
When SOM dt is combined with kd240 overlay DPSUB is enabled but kd240 has
no DP wired that's why change disable it via status property.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-sck-kd-g-revA.dtso | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
index b3fc17cbd577..5202b7c48198 100644
--- a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso
@@ -366,3 +366,7 @@
pinctrl-names = "default";
pinctrl-0 = <_uart1_default>;
};
+
+_dpsub {
+ status = "disabled";
+};
--
2.36.1
[PATCH 3/5] arm64: zynqmp: Align nvmem-fw node with dt-schema
Node name has to be renamed to be aligned with dt-schema and also
xlnx,zynqmp-nvmem-fw switched to fixed-layout.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 125 ---
1 file changed, 64 insertions(+), 61 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index e539fa329e19..855a97077d98 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -207,68 +207,71 @@
mbox-names = "tx", "rx";
};
- nvmem-firmware {
+ soc-nvmem {
compatible = "xlnx,zynqmp-nvmem-fw";
- #address-cells = <1>;
- #size-cells = <1>;
-
- soc_revision: soc-revision@0 {
- reg = <0x0 0x4>;
- };
- /* efuse access */
- efuse_dna: efuse-dna@c {
- reg = <0xc 0xc>;
- };
- efuse_usr0: efuse-usr0@20 {
- reg = <0x20 0x4>;
- };
- efuse_usr1: efuse-usr1@24 {
- reg = <0x24 0x4>;
- };
- efuse_usr2: efuse-usr2@28 {
- reg = <0x28 0x4>;
- };
- efuse_usr3: efuse-usr3@2c {
- reg = <0x2c 0x4>;
- };
- efuse_usr4: efuse-usr4@30 {
- reg = <0x30 0x4>;
- };
- efuse_usr5: efuse-usr5@34 {
- reg = <0x34 0x4>;
- };
- efuse_usr6: efuse-usr6@38 {
- reg = <0x38 0x4>;
- };
- efuse_usr7: efuse-usr7@3c {
- reg = <0x3c 0x4>;
- };
- efuse_miscusr: efuse-miscusr@40 {
- reg = <0x40 0x4>;
- };
- efuse_chash: efuse-chash@50 {
- reg = <0x50 0x4>;
- };
- efuse_pufmisc: efuse-pufmisc@54 {
- reg = <0x54 0x4>;
- };
- efuse_sec: efuse-sec@58 {
- reg = <0x58 0x4>;
- };
- efuse_spkid: efuse-spkid@5c {
- reg = <0x5c 0x4>;
- };
- efuse_aeskey: efuse-aeskey@60 {
- reg = <0x60 0x20>;
- };
- efuse_ppk0hash: efuse-ppk0hash@a0 {
- reg = <0xa0 0x30>;
- };
- efuse_ppk1hash: efuse-ppk1hash@d0 {
- reg = <0xd0 0x30>;
- };
- efuse_pufuser: efuse-pufuser@100 {
- reg = <0x100 0x7F>;
+nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ soc_revision: soc-revision@0 {
+ reg = <0x0 0x4>;
+ };
+ /* efuse access */
+ efuse_dna: efuse-dna@c {
+ reg = <0xc 0xc>;
+ };
+ efuse_usr0: efuse-usr0@20 {
+ reg = <0x20 0x4>;
+ };
+ efuse_usr1: efuse-usr1@24 {
+ reg = <0x24 0x4>;
+ };
+ efuse_usr2: efuse-usr2@28 {
+ reg = <0x28 0x4>;
+ };
+
[PATCH 2/5] arm64: zynqmp: Remove arm,cortex-a53-edac node
There is no dt schema associated with it. Also Linux driver have been
removed in Xilinx Linux tree and never gets to upstream that's why remove
description for it.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index ee2fbcaedc52..e539fa329e19 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -303,10 +303,6 @@
;
};
- edac {
- compatible = "arm,cortex-a53-edac";
- };
-
fpga_full: fpga-region {
compatible = "fpga-region";
fpga-mgr = <_pcap>;
--
2.36.1
[PATCH 1/5] xilinx: Fix fpga region DT nodes name
fpga-full is not aligned with the latest dt-schema. Generic name
fpga-region should be used.
Signed-off-by: Michal Simek
---
Aligned with fpga-region dt schema
https://lore.kernel.org/all/37b107d86b39ef4bc9c482b57b27de8b92c3fa43.1706530726.git.michal.si...@amd.com/
---
arch/arm/dts/zynq-7000.dtsi | 2 +-
arch/arm/dts/zynqmp.dtsi| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
index f8c786ab0b7b..75dfd2f069da 100644
--- a/arch/arm/dts/zynq-7000.dtsi
+++ b/arch/arm/dts/zynq-7000.dtsi
@@ -44,7 +44,7 @@
};
};
- fpga_full: fpga-full {
+ fpga_full: fpga-region {
compatible = "fpga-region";
fpga-mgr = <>;
#address-cells = <1>;
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 63238c08780d..ee2fbcaedc52 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -307,7 +307,7 @@
compatible = "arm,cortex-a53-edac";
};
- fpga_full: fpga-full {
+ fpga_full: fpga-region {
compatible = "fpga-region";
fpga-mgr = <_pcap>;
#address-cells = <2>;
--
2.36.1
Re: [PATCH v3 17/36] mach-snapdragon: generalise board support
On Tue, 30 Jan 2024 at 19:35, Caleb Connolly wrote: > > Historically, Qualcomm boards have relied on heavy hardcoding in U-Boot, > in many cases to the specific SoC but also to the board itself (e.g. > memory map). This has been largely resolved by modernising the Qualcomm > drivers in U-Boot, however the board code still largely follows this > model. > > This patch removes the board specific memory maps and duplicated board > init code, replacing it with generic init code. > > The memory map is now built at runtime based on data read from DT, this > allows for the memory map to be provided without having to recompile > U-Boot. Support is also added for booting with appended DTBs, so that > the first-stage bootloader can populate the memory map for us. > > The sdm845 specific init code is dropped entirely, it set an environment > variable depending on if a button was pressed, but this variable wasn't > used in U-Boot, and could be written to use the button command instead. > > The KASLR detection is also dropped as with appended dtb, the kaslr seed > can be read directly from the DTB passed to U-Boot. > > A new qcom_defconfig is added, with the aim of providing a generic > U-Boot configuration that will work on as many Qualcomm boards as > possible. It replaces the defconfig files for the Dragonboard 845c, > Galaxy S9, and QCS404 EVB. For now the db410c and 820c are excluded as > they still have some board code left. > > Similarly, the config headers for db845c, starqltechn, and qcs404-evb > are replaced by a single qcom header. > > The previously db410c-specific board_usb_init() function is made to be > generic and is added to mach-snapdragon. While we lack proper modelling > for USB configuration, using a well-known named pinctrl state is a > reasonably generic middleground, and works using upstream DT. This > function will do nothing unless the USB node has a pinctrl state named > "device", in which case it will be set when entering USB peripheral > mode. > > Reviewed-by: Neil Armstrong > Signed-off-by: Caleb Connolly > --- > arch/arm/Kconfig | 3 + > arch/arm/dts/Makefile| 9 +- > arch/arm/mach-snapdragon/Kconfig | 96 ++ > arch/arm/mach-snapdragon/Makefile| 6 +- > arch/arm/mach-snapdragon/board.c | 216 > +++ > arch/arm/mach-snapdragon/init_sdm845.c | 73 > arch/arm/mach-snapdragon/sysmap-apq8016.c| 31 > arch/arm/mach-snapdragon/sysmap-apq8096.c| 31 > arch/arm/mach-snapdragon/sysmap-qcs404.c | 43 - > arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 > board/qualcomm/dragonboard410c/Kconfig | 15 -- > board/qualcomm/dragonboard410c/dragonboard410c.c | 41 - > board/qualcomm/dragonboard820c/Kconfig | 15 -- > board/qualcomm/dragonboard820c/dragonboard820c.c | 39 +--- > board/qualcomm/dragonboard845c/Kconfig | 12 -- > board/qualcomm/qcs404-evb/Kconfig| 15 -- > board/qualcomm/qcs404-evb/qcs404-evb.c | 21 +-- > configs/dragonboard410c_defconfig| 6 +- > configs/dragonboard820c_defconfig| 6 +- > configs/dragonboard845c_defconfig| 29 --- > configs/qcom_defconfig | 73 > configs/qcs404evb_defconfig | 5 +- > configs/starqltechn_defconfig| 41 - > include/configs/dragonboard845c.h| 20 --- > include/configs/qcom.h | 21 +++ > include/configs/qcs404-evb.h | 20 --- > include/configs/sdm845.h | 26 --- > 27 files changed, 352 insertions(+), 592 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 9e73b69f1e1f..03ea75cefc0d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1085,6 +1085,9 @@ config ARCH_SNAPDRAGON > select OF_SEPARATE > select SMEM > select SPMI > + select OF_BOARD > + select SAVE_PREV_BL_FDT_ADDR > + select LINUX_KERNEL_IMAGE_HEADER > imply CMD_DM > > config ARCH_SOCFPGA > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 773c2546131c..b058def774d4 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -628,10 +628,11 @@ dtb-$(CONFIG_TARGET_SL28) += > fsl-ls1028a-kontron-sl28.dtb \ > > dtb-$(CONFIG_TARGET_TEN64) += fsl-ls1088a-ten64.dtb > > -dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb > -dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb > -dtb-$(CONFIG_TARGET_STARQLTECHN) += starqltechn.dtb > -dtb-$(CONFIG_TARGET_QCS404EVB) += qcs404-evb.dtb > +dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb \ > + dragonboard820c.dtb \ > + dragonboard845c.dtb \ > + starqltechn.dtb \ > + qcs404-evb.dtb > >
Re: [PATCH v3 33/36] dts: qcs404-evb: replace with upstream DT
On Tue, 30 Jan 2024 at 19:35, Caleb Connolly wrote:
>
> Drop the U-Boot specific DTS in favour of upstream. We'll only include
> the -4000 variant as that is what U-Boot already supported.
>
> Taken from kernel tag v6.7
>
> Reviewed-by: Neil Armstrong
> Signed-off-by: Caleb Connolly
> ---
> arch/arm/dts/Makefile|2 +-
> arch/arm/dts/pms405.dtsi | 149 +++
> arch/arm/dts/qcs404-evb-4000-u-boot.dtsi | 26 +
> arch/arm/dts/qcs404-evb-4000.dts | 96 ++
> arch/arm/dts/qcs404-evb-uboot.dtsi | 30 -
> arch/arm/dts/qcs404-evb.dts | 390 ---
> arch/arm/dts/qcs404-evb.dtsi | 389 +++
> arch/arm/dts/qcs404.dtsi | 1829
> ++
> 8 files changed, 2490 insertions(+), 421 deletions(-)
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 03b199d04692..243069c631aa 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -632,7 +632,7 @@ dtb-$(CONFIG_ARCH_SNAPDRAGON) += apq8016-sbc.dtb \
> apq8096-db820c.dtb \
> sdm845-db845c.dtb \
> sdm845-samsung-starqltechn.dtb \
> - qcs404-evb.dtb
> + qcs404-evb-4000.dtb
>
> dtb-$(CONFIG_TARGET_STEMMY) += ste-ux500-samsung-stemmy.dtb
>
> diff --git a/arch/arm/dts/pms405.dtsi b/arch/arm/dts/pms405.dtsi
> new file mode 100644
> index ..461ad97032f7
> --- /dev/null
> +++ b/arch/arm/dts/pms405.dtsi
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + thermal-zones {
> + pms405-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = <_temp>;
> +
> + trips {
> + pms405_alert0: pms405-alert0 {
> + temperature = <105000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + pms405_crit: pms405-crit {
> + temperature = <125000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +};
> +
> +_bus {
> + pms405_0: pms405@0 {
> + compatible = "qcom,pms405", "qcom,spmi-pmic";
> + reg = <0x0 SPMI_USID>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pms405_gpios: gpio@c000 {
> + compatible = "qcom,pms405-gpio", "qcom,spmi-gpio";
> + reg = <0xc000>;
> + gpio-controller;
> + gpio-ranges = <_gpios 0 0 12>;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + pon@800 {
> + compatible = "qcom,pms405-pon";
> + reg = <0x0800>;
> + mode-bootloader = <0x2>;
> + mode-recovery = <0x1>;
> +
> + pwrkey {
> + compatible = "qcom,pm8941-pwrkey";
> + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
> + debounce = <15625>;
> + bias-pull-up;
> + linux,code = ;
> + };
> + };
> +
> + pms405_temp: temp-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400>;
> + interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;
> + io-channels = <_adc ADC5_DIE_TEMP>;
> + io-channel-names = "thermal";
> + #thermal-sensor-cells = <0>;
> + };
> +
> + pms405_adc: adc@3100 {
> + compatible = "qcom,pms405-adc", "qcom,spmi-adc-rev2";
> + reg = <0x3100>;
> + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + channel@0 {
> + reg = ;
> + qcom,pre-scaling = <1 1>;
> + label = "ref_gnd";
> + };
> +
> + channel@1 {
> + reg = ;
> +
u-boot on iMX.RT117x NOR
Hi, I just found out that u-boot has some support for RT117x, this is great! I could not find a better forum to ask, I will appreciate a redirect. I need u-boot to boot from the SPI NOR flash, I have the EVKB evaluation board. The SPL that is generated is not ELF and no instructions of how to use it are available. I am using NXP-MCUBootUtility to flash in SWD mode, not sure what I should configure and how. I tried to place this on top of the flash as raw binary and it does not work, I am waiting for a life sign at UART1 which is redirected to the debug USB port, as far as I saw the SPL should output a string to the console once started. Any hint of how to progress? Any documentation? It would be exciting to have u-boot as a bootloader. Thanks, Alon
Re: [PATCH v3 33/36] dts: qcs404-evb: replace with upstream DT
On Tue, 30 Jan 2024 at 19:35, Caleb Connolly wrote:
>
> Drop the U-Boot specific DTS in favour of upstream. We'll only include
> the -4000 variant as that is what U-Boot already supported.
>
> Taken from kernel tag v6.7
>
> Reviewed-by: Neil Armstrong
> Signed-off-by: Caleb Connolly
> ---
> arch/arm/dts/Makefile|2 +-
> arch/arm/dts/pms405.dtsi | 149 +++
> arch/arm/dts/qcs404-evb-4000-u-boot.dtsi | 26 +
> arch/arm/dts/qcs404-evb-4000.dts | 96 ++
> arch/arm/dts/qcs404-evb-uboot.dtsi | 30 -
> arch/arm/dts/qcs404-evb.dts | 390 ---
> arch/arm/dts/qcs404-evb.dtsi | 389 +++
> arch/arm/dts/qcs404.dtsi | 1829
> ++
> 8 files changed, 2490 insertions(+), 421 deletions(-)
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 03b199d04692..243069c631aa 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -632,7 +632,7 @@ dtb-$(CONFIG_ARCH_SNAPDRAGON) += apq8016-sbc.dtb \
> apq8096-db820c.dtb \
> sdm845-db845c.dtb \
> sdm845-samsung-starqltechn.dtb \
> - qcs404-evb.dtb
> + qcs404-evb-4000.dtb
>
> dtb-$(CONFIG_TARGET_STEMMY) += ste-ux500-samsung-stemmy.dtb
>
> diff --git a/arch/arm/dts/pms405.dtsi b/arch/arm/dts/pms405.dtsi
> new file mode 100644
> index ..461ad97032f7
> --- /dev/null
> +++ b/arch/arm/dts/pms405.dtsi
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + thermal-zones {
> + pms405-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = <_temp>;
> +
> + trips {
> + pms405_alert0: pms405-alert0 {
> + temperature = <105000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + pms405_crit: pms405-crit {
> + temperature = <125000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +};
> +
> +_bus {
> + pms405_0: pms405@0 {
> + compatible = "qcom,pms405", "qcom,spmi-pmic";
> + reg = <0x0 SPMI_USID>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pms405_gpios: gpio@c000 {
> + compatible = "qcom,pms405-gpio", "qcom,spmi-gpio";
> + reg = <0xc000>;
> + gpio-controller;
> + gpio-ranges = <_gpios 0 0 12>;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + pon@800 {
> + compatible = "qcom,pms405-pon";
> + reg = <0x0800>;
> + mode-bootloader = <0x2>;
> + mode-recovery = <0x1>;
> +
> + pwrkey {
> + compatible = "qcom,pm8941-pwrkey";
> + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
> + debounce = <15625>;
> + bias-pull-up;
> + linux,code = ;
> + };
> + };
> +
> + pms405_temp: temp-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400>;
> + interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;
> + io-channels = <_adc ADC5_DIE_TEMP>;
> + io-channel-names = "thermal";
> + #thermal-sensor-cells = <0>;
> + };
> +
> + pms405_adc: adc@3100 {
> + compatible = "qcom,pms405-adc", "qcom,spmi-adc-rev2";
> + reg = <0x3100>;
> + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + channel@0 {
> + reg = ;
> + qcom,pre-scaling = <1 1>;
> + label = "ref_gnd";
> + };
> +
> + channel@1 {
> + reg = ;
> +
RE: [PATCH] dts: ast2600: add x4tf dts for asus product
Hi, Tom,
Q:
> + model = "AST2600 ASUS";
> + compatible = "aspeed,ast2600-asus", "aspeed,ast2600";
A: I do a modification, replace "ast2600-evb" with "ast2600-asus".
Q: All of these are bootph* now.
And is there effort being made to upstream the dts files for these platforms to
Linux?
A: Yes, I also git send-email to kernel related persons to add a asus dts in
kernel device tree.
My typo, I would like to correct it.
> @@ -0,0 +1,239 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2023 ASUS Corp.
Thans for review.
Best Regards
Kelly
-Original Message-
From: Tom Rini
Sent: Tuesday, January 30, 2024 11:09 PM
To: Kelly Hung
Cc: u-boot@lists.denx.de; open...@lists.ozlabs.org; Kelly Hung(洪嘉莉)
Subject: Re: [PATCH] dts: ast2600: add x4tf dts for asus product
On Tue, Jan 30, 2024 at 06:40:45PM +0800, Kelly Hung wrote:
> This initial device-tree provides the necessary configuration for
> basic BMC functionality and work on ASUS X4TF production.
>
> Signed-off-by: Kelly Hung
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/ast2600-x4tf.dts | 239
> ++
[snip]
> diff --git a/arch/arm/dts/ast2600-x4tf.dts
> b/arch/arm/dts/ast2600-x4tf.dts new file mode 100644 index
> ..3c478058
> --- /dev/null
> +++ b/arch/arm/dts/ast2600-x4tf.dts
> @@ -0,0 +1,239 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2020 IBM Corp.
> +/dts-v1/;
> +
> +#include "ast2600-u-boot.dtsi"
> +
> +/ {
> + model = "AST2600 ASUS";
> + compatible = "aspeed,ast2600-evb", "aspeed,ast2600";
Compatible should be board unique.
> + {
> + u-boot,dm-pre-reloc;
All of these are bootph* now.
And is there effort being made to upstream the dts files for these platforms to
Linux?
--
Tom
===
This email and any attachments to it contain confidential information and are
intended solely for the use of the individual to whom it is addressed. If you
are not the intended recipient or receive it accidentally, please immediately
notify the sender by e-mail and delete the message and any attachments from
your computer system, and destroy all hard copies. Please be advised that any
unauthorized disclosure, copying, distribution or any action taken or omitted
in reliance on this, is illegal and prohibited. Any views or opinions expressed
are solely those of the author and do not represent those of ASUSTeK.
For pricing information, ASUS is only entitled to set a recommendation resale
price. All customers are free to set their own price as they wish.
===
RE: [PATCH] dts: ast2600: add x4tf dts for asus product
Hi, Tom,
> + model = "AST2600 ASUS";
> + compatible = "aspeed,ast2600-asus", "aspeed,ast2600";
I do a modification, replace "asus2600-evb" with "ast2600-asus".
All of these are bootph* now.
And is there effort being made to upstream the dts files for these platforms to
Linux?
Yes, I also git send-email to kernel related persons to add a asus dts in
kernel device tree.
Thans for review.
Best Regards
Kelly
-Original Message-
From: Tom Rini
Sent: Tuesday, January 30, 2024 11:09 PM
To: Kelly Hung
Cc: u-boot@lists.denx.de; open...@lists.ozlabs.org; Kelly Hung(洪嘉莉)
Subject: Re: [PATCH] dts: ast2600: add x4tf dts for asus product
On Tue, Jan 30, 2024 at 06:40:45PM +0800, Kelly Hung wrote:
> This initial device-tree provides the necessary configuration for
> basic BMC functionality and work on ASUS X4TF production.
>
> Signed-off-by: Kelly Hung
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/ast2600-x4tf.dts | 239
> ++
[snip]
> diff --git a/arch/arm/dts/ast2600-x4tf.dts
> b/arch/arm/dts/ast2600-x4tf.dts new file mode 100644 index
> ..3c478058
> --- /dev/null
> +++ b/arch/arm/dts/ast2600-x4tf.dts
> @@ -0,0 +1,239 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2020 IBM Corp.
> +/dts-v1/;
> +
> +#include "ast2600-u-boot.dtsi"
> +
> +/ {
> + model = "AST2600 ASUS";
> + compatible = "aspeed,ast2600-evb", "aspeed,ast2600";
Compatible should be board unique.
> + {
> + u-boot,dm-pre-reloc;
All of these are bootph* now.
And is there effort being made to upstream the dts files for these platforms to
Linux?
--
Tom
===
This email and any attachments to it contain confidential information and are
intended solely for the use of the individual to whom it is addressed. If you
are not the intended recipient or receive it accidentally, please immediately
notify the sender by e-mail and delete the message and any attachments from
your computer system, and destroy all hard copies. Please be advised that any
unauthorized disclosure, copying, distribution or any action taken or omitted
in reliance on this, is illegal and prohibited. Any views or opinions expressed
are solely those of the author and do not represent those of ASUSTeK.
For pricing information, ASUS is only entitled to set a recommendation resale
price. All customers are free to set their own price as they wish.
===
[RFC PATCH v2 2/2] board: ad401: example of fastboot oem board realization
An example of how we use fastboot oeam board subcommand
for Sean Anderson.
1 - OEM_BOARD_WRITE_BOOTLOADER_CMD:
We use it for custom Amlogic bootloader + tpl
flashing protocol.
2 - OEM_BOARD_ERASE_CMD:
Custom logic for erasing the env-emulated partition,
which isn't in the mtd markup map.
Example of the script which completely flashes the device:
$ fastboot erase bootloader
$ fastboot stage u-boot.bin
$ fastboot oem board:write_bootloader
$ fastboot reboot-bootloader
$ fastboot oem board:erase_env
$ fastboot erase misc
$ fastboot erase super
$ fastboot flash super rootfs
$ fastboot reboot
Signed-off-by: Alexey Romanov
---
board/amlogic/ad401/fastboot.c | 222 +
1 file changed, 222 insertions(+)
create mode 100644 board/amlogic/ad401/fastboot.c
diff --git a/board/amlogic/ad401/fastboot.c b/board/amlogic/ad401/fastboot.c
new file mode 100644
index 00..01da8efa5b
--- /dev/null
+++ b/board/amlogic/ad401/fastboot.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 SaluteDevices, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ OEM_BOARD_ERASE_CMD,
+ OEM_BOARD_WRITE_BOOTLOADER_CMD,
+};
+
+struct defenv {
+ char *name;
+ char value[256];
+};
+
+static void save_defenv(struct defenv *e, size_t cnt)
+{
+ int i;
+
+ for (i = 0; i < cnt; i++) {
+ const char *env_val = env_get(e[i].name);
+
+ if (env_val)
+ strlcpy(e[i].value, env_val, sizeof(e[i].value));
+ else
+ e[i].value[0] = '\0';
+ }
+}
+
+static void set_defenv(struct defenv *e, size_t cnt)
+{
+ int i;
+
+ for (i = 0; i < cnt; i++)
+ env_set(e[i].name, e[i].value);
+}
+
+static int fastboot_erase_env(void)
+{
+ char *const defenv_names[] = { "lock", "mtdparts", "mtdids" };
+ struct defenv env[ARRAY_SIZE(defenv_names)];
+ int err, i;
+
+ for (i = 0; i < ARRAY_SIZE(env); i++)
+ env[i].name = defenv_names[i];
+
+ printf("ENV is being erased...\n");
+
+ /*
+* Reset environment to the default, excluding 'lock' variable,
+* because it reflects the fastboot's state after execution of
+* 'flashing unlock' command, hence it must survive the env-erasing.
+* Otherwise, further erase commands will fail on check_lock().
+*
+* Also, we have to save 'mtdparts' and 'mtdids' variables
+* because they are necessary to obtain partition map.
+*/
+
+ save_defenv(env, ARRAY_SIZE(env));
+ env_set_default(NULL, 0);
+ set_defenv(env, ARRAY_SIZE(env));
+
+ err = env_save();
+ if (err) {
+ pr_err("Can't overwrite ENV-partition\n");
+ return err;
+ }
+
+ return 0;
+}
+
+static int fastboot_nand_write_tpl(struct mtd_info *mtd, void *buffer,
+ u32 offset, size_t size, int flags)
+{
+ int boot_cpy_num = meson_bootloader_copy_num(BOOT_TPL);
+ u64 size_per_copy = meson_bootloader_copy_size(mtd, BOOT_TPL);
+ int i;
+
+ for (i = 0; i < boot_cpy_num; i++) {
+ size_t retlen, len = size;
+ int ret;
+
+ ret = nand_write_skip_bad(mtd, offset + (i * size_per_copy),
+ , , offset + size_per_copy,
+ buffer, flags);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int fastboot_nand_write_bl2(struct mtd_info *mtd, void *buffer,
+ u32 offset, size_t size, int flags)
+{
+ int boot_cpy_num = meson_bootloader_copy_num(BOOT_BL2);
+ u64 size_per_copy = meson_bootloader_copy_size(mtd, BOOT_BL2);
+ int i;
+
+ for (i = 0; i < boot_cpy_num; i++) {
+ int ret;
+
+ ret = meson_bootloader_write_bl2(mtd, buffer,
+offset + (i * size_per_copy),
+size, flags);
+ if (ret)
+ return ret;
+ }
+
+ return meson_bootloader_write_info_pages();
+}
+
+static int fastboot_nand_write_bootloader(void *buffer, u32 size)
+{
+ struct part_info *part;
+ struct mtd_info *mtd = NULL;
+ struct mtd_device *dev;
+ u8 pnum;
+ int ret;
+
+ if (size < BL2_SIZE)
+ return 0;
+
+ if (!buffer)
+ return -EINVAL;
+
+ ret = mtdparts_init();
+ if (ret) {
+ pr_err("Cannot initialize MTD partitions\n");
+ return ret;
+ }
+
+ ret = find_dev_and_part("bootloader", , , );
+ if (ret) {
+ pr_err("cannot find 'bootloader' partition\n");
+ return ret;
+
[RFC PATCH v2 1/2] fastboot: introduce 'oem board' subcommand
Currently, fastboot protocol in U-Boot has no opportunity
to execute vendor custom code with verifed boot. This patch
introduce new fastboot subcommand fastboot oem board:,
which allow to run custom oem_board function.
Default implementation is __weak. Vendor must redefine it in
board/ folder with his own logic.
For example, some vendors have their custom nand/emmc partition
flashing or erasing. Here some typical command for such use cases:
- flashing:
$ fastboot stage bootloader.img
$ fastboot oem board:write_bootloader
- erasing:
$ fastboot oem board:erase_env
Signed-off-by: Alexey Romanov
---
drivers/fastboot/Kconfig | 7 +++
drivers/fastboot/fb_command.c | 15 +++
include/fastboot.h| 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index a4313d60a9..4d94391a76 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN
this feature if you are using verified boot, as it will allow an
attacker to bypass any restrictions you have in place.
+config FASTBOOT_OEM_BOARD
+ bool "Enable the 'oem board' command"
+ help
+ This extends the fastboot protocol with an "oem board" command. This
+ command allows running vendor custom code defined in board/ files.
+ Otherwise, it will do nothing and send fastboot fail.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 5fcadcdf50..2298815770 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -40,6 +40,7 @@ static void reboot_recovery(char *, char *);
static void oem_format(char *, char *);
static void oem_partconf(char *, char *);
static void oem_bootbus(char *, char *);
+static void oem_board(char *, char *);
static void run_ucmd(char *, char *);
static void run_acmd(char *, char *);
@@ -107,6 +108,10 @@ static const struct {
.command = "oem run",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd),
(NULL))
},
+ [FASTBOOT_COMMAND_OEM_BOARD] = {
+ .command = "oem board",
+ .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_BOARD, (oem_board),
(NULL))
+ },
[FASTBOOT_COMMAND_UCMD] = {
.command = "UCmd",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd),
(NULL))
@@ -490,3 +495,13 @@ static void __maybe_unused oem_bootbus(char
*cmd_parameter, char *response)
else
fastboot_okay(NULL, response);
}
+
+void __weak fastboot_oem_board(char *cmd_parameter, void *data, u32 size, char
*response)
+{
+ fastboot_fail("oem board function not defined", response);
+}
+
+static void __maybe_unused oem_board(char *cmd_parameter, char *response)
+{
+ fastboot_oem_board(cmd_parameter, fastboot_buf_addr, image_size,
response);
+}
diff --git a/include/fastboot.h b/include/fastboot.h
index 296451f89d..06c1f26b6c 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -37,6 +37,7 @@ enum {
FASTBOOT_COMMAND_OEM_PARTCONF,
FASTBOOT_COMMAND_OEM_BOOTBUS,
FASTBOOT_COMMAND_OEM_RUN,
+ FASTBOOT_COMMAND_OEM_BOARD,
FASTBOOT_COMMAND_ACMD,
FASTBOOT_COMMAND_UCMD,
FASTBOOT_COMMAND_COUNT
--
2.30.1
[RFC PATCH v2 0/2] Introduce fastboot oem board command
Changes v2 since v1 at [1]: - Added an example of using the command as requsted by Sean Anderson [2]. Links: [1] https://lore.kernel.org/all/20231228152522.83291-1-avroma...@salutedevices.com/ [2] https://lore.kernel.org/all/72ac233d-c18d-4f57-bc66-451fe0bd2...@seco.com/ Alexey Romanov (2): fastboot: introduce 'oem board' subcommand board: ad401: example of fastboot oem board realization board/amlogic/ad401/fastboot.c | 222 + drivers/fastboot/Kconfig | 7 ++ drivers/fastboot/fb_command.c | 15 +++ include/fastboot.h | 1 + 4 files changed, 245 insertions(+) create mode 100644 board/amlogic/ad401/fastboot.c -- 2.30.1
[PATCH v2 10/13] arm: dts: introduce am62p5 uboot dts files
Include the uboot device tree files needed to boot the board. Signed-off-by: Bryan Brattlof --- arch/arm/dts/Makefile |2 + arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi | 2800 arch/arm/dts/k3-am62p-sk-binman.dtsi | 173 ++ arch/arm/dts/k3-am62p5-r5-sk.dts | 101 + arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 49 + arch/arm/mach-k3/Makefile |1 + arch/arm/mach-k3/am62p5_init.c |4 +- dts/arch/arm64/ti |1 + 8 files changed, 3129 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi create mode 100644 arch/arm/dts/k3-am62p-sk-binman.dtsi create mode 100644 arch/arm/dts/k3-am62p5-r5-sk.dts create mode 100644 arch/arm/dts/k3-am62p5-sk-u-boot.dtsi create mode 12 dts/arch/arm64/ti diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 34ebf2b58417d..36de84287d4c2 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1424,6 +1424,8 @@ dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \ dtb-$(CONFIG_SOC_K3_AM62A7) += k3-am62a7-sk.dtb \ k3-am62a7-r5-sk.dtb +dtb-$(CONFIG_SOC_K3_AM62P5) += k3-am62p5-r5-sk.dtb + dtb-$(CONFIG_ARCH_MEDIATEK) += \ mt7622-rfb.dtb \ mt7623a-unielec-u7623-02-emmc.dtb \ diff --git a/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi b/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi new file mode 100644 index 0..f66435201530f --- /dev/null +++ b/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi @@ -0,0 +1,2800 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * This file was generated with the + * AM62Px SysConfig DDR Subsystem Register Configuration Tool v0.10.02 + * Thu Jan 25 2024 10:43:46 GMT-0600 (Central Standard Time) + * DDR Type: LPDDR4 + * F0 = 50MHzF1 = NA F2 = 1600MHz + * Density (per channel): 16Gb + * Number of Ranks: 2 + */ + +#define DDRSS_PLL_FHS_CNT 5 +#define DDRSS_PLL_FREQUENCY_1 8 +#define DDRSS_PLL_FREQUENCY_2 8 +#define DDRSS_SDRAM_IDX 17 +#define DDRSS_REGION_IDX 17 + +#define DDRSS_CTL_0_DATA 0x0B00 +#define DDRSS_CTL_1_DATA 0x +#define DDRSS_CTL_2_DATA 0x +#define DDRSS_CTL_3_DATA 0x +#define DDRSS_CTL_4_DATA 0x +#define DDRSS_CTL_5_DATA 0x +#define DDRSS_CTL_6_DATA 0x +#define DDRSS_CTL_7_DATA 0x2710 +#define DDRSS_CTL_8_DATA 0x000186A0 +#define DDRSS_CTL_9_DATA 0x0005 +#define DDRSS_CTL_10_DATA 0x0064 +#define DDRSS_CTL_11_DATA 0x0004E200 +#define DDRSS_CTL_12_DATA 0x0030D400 +#define DDRSS_CTL_13_DATA 0x0005 +#define DDRSS_CTL_14_DATA 0x0C80 +#define DDRSS_CTL_15_DATA 0x0004E200 +#define DDRSS_CTL_16_DATA 0x0030D400 +#define DDRSS_CTL_17_DATA 0x0005 +#define DDRSS_CTL_18_DATA 0x0C80 +#define DDRSS_CTL_19_DATA 0x01010100 +#define DDRSS_CTL_20_DATA 0x01010100 +#define DDRSS_CTL_21_DATA 0x01000110 +#define DDRSS_CTL_22_DATA 0x02010002 +#define DDRSS_CTL_23_DATA 0x000A +#define DDRSS_CTL_24_DATA 0x000186A0 +#define DDRSS_CTL_25_DATA 0x +#define DDRSS_CTL_26_DATA 0x +#define DDRSS_CTL_27_DATA 0x +#define DDRSS_CTL_28_DATA 0x +#define DDRSS_CTL_29_DATA 0x00020200 +#define DDRSS_CTL_30_DATA 0x +#define DDRSS_CTL_31_DATA 0x +#define DDRSS_CTL_32_DATA 0x +#define DDRSS_CTL_33_DATA 0x +#define DDRSS_CTL_34_DATA 0x0810 +#define DDRSS_CTL_35_DATA 0x4040 +#define DDRSS_CTL_36_DATA 0x +#define DDRSS_CTL_37_DATA 0x +#define DDRSS_CTL_38_DATA 0x +#define DDRSS_CTL_39_DATA 0x +#define DDRSS_CTL_40_DATA 0x040C +#define DDRSS_CTL_41_DATA 0x +#define DDRSS_CTL_42_DATA 0x0E38 +#define DDRSS_CTL_43_DATA 0x +#define DDRSS_CTL_44_DATA 0x0E38 +#define DDRSS_CTL_45_DATA 0x +#define DDRSS_CTL_46_DATA 0x05000804 +#define DDRSS_CTL_47_DATA 0x0700 +#define DDRSS_CTL_48_DATA 0x09090004 +#define DDRSS_CTL_49_DATA 0x0303 +#define DDRSS_CTL_50_DATA 0x00620011 +#define DDRSS_CTL_51_DATA 0x09110045 +#define DDRSS_CTL_52_DATA 0x421D +#define DDRSS_CTL_53_DATA 0x00620011 +#define DDRSS_CTL_54_DATA 0x09110045 +#define DDRSS_CTL_55_DATA 0x0900421D +#define DDRSS_CTL_56_DATA 0x000A0A09 +#define DDRSS_CTL_57_DATA 0x040006DB +#define DDRSS_CTL_58_DATA 0x090D2005 +#define DDRSS_CTL_59_DATA 0x1710 +#define DDRSS_CTL_60_DATA 0x0C00DB60 +#define DDRSS_CTL_61_DATA 0x090D200D +#define DDRSS_CTL_62_DATA 0x1710 +#define DDRSS_CTL_63_DATA 0x0C00DB60 +#define DDRSS_CTL_64_DATA 0x0304200D +#define DDRSS_CTL_65_DATA 0x04050002 +#define DDRSS_CTL_66_DATA 0x1F1E1F1E +#define DDRSS_CTL_67_DATA 0x01010008 +#define DDRSS_CTL_68_DATA 0x043C3C07 +#define DDRSS_CTL_69_DATA 0x0303 +#define DDRSS_CTL_70_DATA 0x +#define DDRSS_CTL_71_DATA 0x0101 +#define DDRSS_CTL_72_DATA 0x +#define DDRSS_CTL_73_DATA 0x0100 +#define DDRSS_CTL_74_DATA 0x00130803 +#define DDRSS_CTL_75_DATA 0x00BB +#define
Re: [PATCH v3 20/36] mach-snapdragon: carve out no-map regions
On Tue, 30 Jan 2024 at 19:35, Caleb Connolly wrote:
>
> On Qualcomm platforms, the TZ may already have certain memory regions
> under protection by the time U-Boot starts. There is a rare case on some
> platforms where the prefetcher might speculatively access one of these
> regions resulting in a board crash (TZ traps and then resets the board).
>
> We shouldn't be accessing these regions from within U-Boot anyway, so
> let's mark them all with PTE_TYPE_FAULT to prevent any speculative
> access and correctly trap in EL1 rather than EL3.
>
> This is quite costly with caches off (takes ~2 seconds on SDM845 vs 35ms
> with caches on). So to minimise the impact this is only enabled on
> QCS404 for now (where the issue is known to occur).
It only took 65ms with caches off on QCS404 as per below print:
carveout time: 65ms
It's probably due to some missing bits as pointed below to get it
working fast on SDM845 too..
>
> In the future, we should try to find a more efficient way to handle
> this, perhaps by turning on the MMU in stages.
>
> Signed-off-by: Caleb Connolly
> ---
> abort| 20 ++
> arch/arm/mach-snapdragon/board.c | 151
> ---
> 2 files changed, 147 insertions(+), 24 deletions(-)
>
> diff --git a/abort b/abort
> new file mode 100644
> index ..34c3e2f0596a
> --- /dev/null
> +++ b/abort
> @@ -0,0 +1,20 @@
> +"Synchronous Abort" handler, esr 0x9607, far 0x0
> +elr: 5070 lr : 39a8 (reloc)
> +elr: 00017ff27070 lr : 00017ff259a8
> +x0 : x1 :
> +x2 : 00017faeb328 x3 : 00017faeb320
> +x4 : 000feae8 x5 : feae8000
> +x6 : 0007 x7 : 0004
> +x8 : x9 : 00017eae7000
> +x10: x11: 00027c89
> +x12: 00017fff x13: 00018000
> +x14: 00518db0 x15: 00017faeb0cc
> +x16: 00017ff2edac x17:
> +x18: 00017fb02d50 x19: 00017ffbd600
> +x20: 00017ffbd600 x21:
> +x22: 1f1f x23: 00017faeb370
> +x24: 00017ffbd000 x25: 00017ff94993
> +x26: 0030 x27: 00017ffbecf0
> +x28: x29: 00017faeb2a0
> +
> +Code: a94153f3 f94013f5 a8c47bfd d65f03c0 (b942)
> diff --git a/arch/arm/mach-snapdragon/board.c
> b/arch/arm/mach-snapdragon/board.c
> index 9d8684a21fa1..ca300dc843a9 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -6,8 +6,9 @@
> * Author: Caleb Connolly
> */
>
> -#define LOG_DEBUG
> +//#define LOG_DEBUG
>
> +#include "time.h"
> #include
> #include
> #include
> @@ -26,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -297,7 +299,7 @@ int board_late_init(void)
>
> static void build_mem_map(void)
> {
> - int i;
> + int i, j;
>
> /*
> * Ensure the peripheral block is sized to correctly cover the
> address range
> @@ -313,39 +315,140 @@ static void build_mem_map(void)
> PTE_BLOCK_NON_SHARE |
> PTE_BLOCK_PXN | PTE_BLOCK_UXN;
>
> - debug("Configured memory map:\n");
> - debug(" 0x%016llx - 0x%016llx: Peripheral block\n",
> - mem_map[0].phys, mem_map[0].phys + mem_map[0].size);
> -
> - /*
> -* Now add memory map entries for each DRAM bank, ensuring we don't
> -* overwrite the list terminator
> -*/
> - for (i = 0; i < ARRAY_SIZE(rbx_mem_map) - 2 &&
> gd->bd->bi_dram[i].size; i++) {
> - if (i == ARRAY_SIZE(rbx_mem_map) - 1) {
> - log_warning("Too many DRAM banks!\n");
> - break;
> - }
> - mem_map[i + 1].phys = gd->bd->bi_dram[i].start;
> - mem_map[i + 1].virt = mem_map[i + 1].phys;
> - mem_map[i + 1].size = gd->bd->bi_dram[i].size;
> - mem_map[i + 1].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> -PTE_BLOCK_INNER_SHARE;
> -
> - debug(" 0x%016llx - 0x%016llx: DDR bank %d\n",
> - mem_map[i + 1].phys, mem_map[i + 1].phys + mem_map[i +
> 1].size, i);
> + for (i = 1, j = 0; i < ARRAY_SIZE(rbx_mem_map) - 1 &&
> gd->bd->bi_dram[j].size; i++, j++) {
> + mem_map[i].phys = gd->bd->bi_dram[j].start;
> + mem_map[i].virt = mem_map[i].phys;
> + mem_map[i].size = gd->bd->bi_dram[j].size;
> + mem_map[i].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | \
> + PTE_BLOCK_INNER_SHARE;
> }
> +
> + mem_map[i].phys = UINT64_MAX;
> + mem_map[i].size = 0;
> +
> + debug("Configured memory map:\n");
> + for (i = 0; mem_map[i].size; i++)
> + debug(" 0x%016llx - 0x%016llx: entry %d\n",
> + mem_map[i].phys,
Re: [PATCH v3 1/3] firmware: psci: Fix bind_smccc_features psci check
Hi Weizhao, > - if (request_psci_features(ARM_SMCCC_ARCH_FEATURES) == > + if (request_psci_features(ARM_SMCCC_VERSION) == > PSCI_RET_NOT_SUPPORTED) > return 0; > > + if (invoke_psci_fn(ARM_SMCCC_VERSION, 0, 0, 0) < ARM_SMCCC_VERSION_1_1) > + return 0; It makes sense to me, thanks. > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h > index f44e9e8f93..da3d29aabe 100644 > --- a/include/linux/arm-smccc.h > +++ b/include/linux/arm-smccc.h > @@ -55,8 +55,14 @@ > #define ARM_SMCCC_QUIRK_NONE 0 > #define ARM_SMCCC_QUIRK_QCOM_A6 1 /* Save/restore register a6 */ > > +#define ARM_SMCCC_VERSION0x8000 > #define ARM_SMCCC_ARCH_FEATURES 0x8001 > > +#define ARM_SMCCC_VERSION_1_00x1 > +#define ARM_SMCCC_VERSION_1_10x10001 > +#define ARM_SMCCC_VERSION_1_20x10002 > +#define ARM_SMCCC_VERSION_1_30x10003 Apart from ARM_SMCCC_VERSION_1_1, are the other ARM_SMCCC_VERSION_1_x defines needed ? Cheers, Abdellatif
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On Thu, Feb 1, 2024 at 11:13 AM Marek Vasut wrote: > > On 2/1/24 10:39, Shantur Rathore wrote: > > Hi Andre, > > > > On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara > > wrote: > >> > >> On Sat, 9 Dec 2023 18:10:56 + > >> Shantur Rathore wrote: > >> > >> Hi, > >> > >>> Currently when a hub is turned on, all the ports are powered on. > >>> This works well for hubs which have individual power control. > >>> > >>> For the hubs without individual power control this has no effect. > >>> Mostly in these scenarios the hub port is powered before the USB > >>> controller is enabled, this can lead to some devices in unexpected > >>> state. > >>> > >>> With this patch, we explicitly reset the port while powering up hub > >>> This resets the port for hubs without port power control and has > >>> no effect on hubs with port power control as the port is still off. > >>> > >>> Before this patch AMicro AM8180 based NVME to USB adapter won't be > >>> detected as a USB3.0 Mass Storage device but with this it works as > >>> expected. > >>> > >>> Tested working after this patch: > >>> 1. AMicro AM8180 based NVME to USB Adapter > >>> 2. Kingston DataTraveler 3.0 > >>> 3. GenesysLogic USB3.0 Hub > >>> > >>> The drives were tested while connected directly and via the hub. > >> > >> so this broke USB operation on some Allwinner boards. The ports still > >> enumerate correctly, but no devices are detected. With mainline > >> (containing this patch), and a USB stick connected: > >> starting USB... > >> Bus usb@520: USB EHCI 1.00 > >> Bus usb@5200400: USB OHCI 1.0 > >> scanning bus usb@520 for devices... 1 USB Device(s) found > >> scanning bus usb@5200400 for devices... 1 USB Device(s) found > >> scanning usb for storage devices... 0 Storage Device(s) found > >> > >> With this patch here reverted: > >> starting USB... > >> Bus usb@520: USB EHCI 1.00 > >> Bus usb@5200400: USB OHCI 1.0 > >> scanning bus usb@520 for devices... 2 USB Device(s) found > >> scanning bus usb@5200400 for devices... 1 USB Device(s) found > >> scanning usb for storage devices... 1 Storage Device(s) found > >> > >> I have no clue why this happens, there is no discrete hub anywhere in this > >> setup, so I guess the code runs for the root hub here? > >> I am attaching a log with DEBUG enabled for common/usb_hub.c, for both > >> cases. > >> > >> Any clues, debug suggestions, or even a fix are warmly welcome. > >> > > > > Which USB disk are you using? Is it a USB 2.0 disk ? > > Can you try with any other USB disk to confirm? > > I don't think this is device specific, see the logs. Hardware from Andre > worked before this patch, does not work after this patch. There seem to > be no connection event with this patch. I am trying to evaluate if this is happening due to a USB 2.0 device. I see that the host is USB 2.0. I have tested this on my RK3399 board on both USB 2.0 and USB 3.0 ports. If this is not behaving on USB 2.0 ports then I can put a condition for this to happen only on USB 3.0 ports.
Re: [PATCH v3] common: usb-hub: Reset hub port before scanning
On 2/1/24 10:39, Shantur Rathore wrote: Hi Andre, On Tue, Jan 30, 2024 at 2:01 PM Andre Przywara wrote: On Sat, 9 Dec 2023 18:10:56 + Shantur Rathore wrote: Hi, Currently when a hub is turned on, all the ports are powered on. This works well for hubs which have individual power control. For the hubs without individual power control this has no effect. Mostly in these scenarios the hub port is powered before the USB controller is enabled, this can lead to some devices in unexpected state. With this patch, we explicitly reset the port while powering up hub This resets the port for hubs without port power control and has no effect on hubs with port power control as the port is still off. Before this patch AMicro AM8180 based NVME to USB adapter won't be detected as a USB3.0 Mass Storage device but with this it works as expected. Tested working after this patch: 1. AMicro AM8180 based NVME to USB Adapter 2. Kingston DataTraveler 3.0 3. GenesysLogic USB3.0 Hub The drives were tested while connected directly and via the hub. so this broke USB operation on some Allwinner boards. The ports still enumerate correctly, but no devices are detected. With mainline (containing this patch), and a USB stick connected: starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found With this patch here reverted: starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found I have no clue why this happens, there is no discrete hub anywhere in this setup, so I guess the code runs for the root hub here? I am attaching a log with DEBUG enabled for common/usb_hub.c, for both cases. Any clues, debug suggestions, or even a fix are warmly welcome. Which USB disk are you using? Is it a USB 2.0 disk ? Can you try with any other USB disk to confirm? I don't think this is device specific, see the logs. Hardware from Andre worked before this patch, does not work after this patch. There seem to be no connection event with this patch.
Re: [PATCH 1/3] rockchip: rk35xx: Remove use of eMMC DDR52 mode
Hi Quentin, On 2024-02-01 11:18, Quentin Schulz wrote: > Hi Jonas, > > On 1/27/24 12:15, Jonas Karlman wrote: >> Hi Eugen, >> >> On 2024-01-27 04:48, Eugen Hristev wrote: >>> Hi Jonas, >>> >>> >>> On 1/27/24 01:26, Jonas Karlman wrote: Writing to eMMC using DDR52 mode does not work reliably or at all on RK356x and RK3588 boards. >>> >>> >>> This is related to the old issue I encountered last year with mmc write? >> >> Yes, I think it is. >> >> I did some testing on RK3566/RK3568/RK3588S/RK3588 boards with different >> eMMC modules with following result: >> >> Read seem to work with all enabled modes: >> RK3566: MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), >> MMC DDR52 (52MHz) and HS200 (200MHz) >> RK3568/RK3588S/RK3588: all above + HS400 (200MHz) and HS400ES (200MHz) >> >> However, write had issues with some of the modes: >> MMC DDR52 (52MHz): all RK35xx >> HS400/HS400ES: only on RK3568 after changing hs400_txclk_tapnum to 8 >> >> HS200 seem to be the most stable write speed that worked on all SoCs. >> >> So, dropping MMC DDR52 (52MHz) and enable use of HS200 (200MHz) seem to >> be the best option to get speedy and working read and write eMMC. >> > > 1) we have this enabled on RK3588 Jaguar in upstream Linux... I may have > improperly tested it then, would you mind sharing how you tested this > mode on RK3588 so I can reproduce this and fix it on our product if > we're impacted? I assume because we have HS200/HS400/HS400-ES enabled, > DDR52 would never be used? (our eMMC is soldered and support the former > modes). My main mode of testing eMMC in U-Boot has been to enable following Kconfig options, CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_HS400_ES_SUPPORT=y CONFIG_MMC_SPEED_MODE_SET=y and from U-Boot cli run following, => mmc rescan && mmc info && mmc read 1000 2000 1 => mmc rescan && mmc info && mmc write 2000 4000 1 for each of the modes below. 0 = MMC legacy 1 = MMC High Speed (26MHz) 3 = MMC High Speed (52MHz) 4 = MMC DDR52 (52MHz) 10 = HS200 (200MHz) 11 = HS400 (200MHz) 12 = HS400ES (200MHz) on different boards and different eMMC modules. Using some modes the read or write return ERROR instead of OK. When ERROR was reported a rescan or board reset was needed to test next mode. Please also note that I have only tested in U-Boot, not in linux. > > 2) Why are we not enabling HS400/HS400-ES for RK3588 boards? You seem to > be saying there are issues with HS400/HS400-ES on RK3568 but you didn't > mention the status for RK3588. Did I misunderstand the last sentence? > Can you please rephrase in that case? I can see now that my wording was very confusing. Write for HS400/HS400ES mode only worked on RK3568 after modification to the driver, on RK3588 write always returned error for me. So on RK3568 HS400 modes could be made work, on remaining SoCs there was issues. Regards, Jonas > > Cheers, > Quentin
Please pull u-boot-watchdog/master
Hi Tom, please pull the following watchdog related last minute fixes: - add andes atcwdt200 support (Randolph) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=339=results Thanks, Stefan The following changes since commit b6d8969bcb94321dfed1399f2eaa8768ba42caaa: Merge tag 'u-boot-at91-2024.04-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 (2024-01-31 10:44:33 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git for you to fetch changes up to 094eda0660d419f35e10c49fade75a6738a56137: configs: andes: add watchdog support fot andes ae350 (2024-02-01 09:08:44 +0100) Randolph (2): drivers: watchdog: add andes atcwdt200 support configs: andes: add watchdog support fot andes ae350 configs/ae350_rv32_defconfig | 4 + configs/ae350_rv32_spl_defconfig | 4 + configs/ae350_rv32_spl_xip_defconfig | 4 + configs/ae350_rv32_xip_defconfig | 4 + configs/ae350_rv64_defconfig | 4 + configs/ae350_rv64_spl_defconfig | 4 + configs/ae350_rv64_spl_xip_defconfig | 4 + configs/ae350_rv64_xip_defconfig | 4 + drivers/watchdog/Kconfig | 6 + drivers/watchdog/Makefile| 1 + drivers/watchdog/atcwdt200_wdt.c | 220 +++ 11 files changed, 259 insertions(+) create mode 100644 drivers/watchdog/atcwdt200_wdt.c
Re: [PATCH V4 2/2] configs: andes: add watchdog support fot andes ae350
On 1/24/24 07:21, Randolph wrote: It adds the ATCWDT200 support for Andes AE350 platform. It also enables wdt command support. Signed-off-by: CL Wang Signed-off-by: Randolph Reviewed-by: Leo Yu-Chi Liang Applied to u-boot-watchdog/master Thanks, Stefan --- configs/ae350_rv32_defconfig | 4 configs/ae350_rv32_spl_defconfig | 4 configs/ae350_rv32_spl_xip_defconfig | 4 configs/ae350_rv32_xip_defconfig | 4 configs/ae350_rv64_defconfig | 4 configs/ae350_rv64_spl_defconfig | 4 configs/ae350_rv64_spl_xip_defconfig | 4 configs/ae350_rv64_xip_defconfig | 4 8 files changed, 32 insertions(+) diff --git a/configs/ae350_rv32_defconfig b/configs/ae350_rv32_defconfig index 3bfa3e9f8e..35ad62c845 100644 --- a/configs/ae350_rv32_defconfig +++ b/configs/ae350_rv32_defconfig @@ -23,6 +23,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -49,3 +50,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_spl_defconfig b/configs/ae350_rv32_spl_defconfig index aeb50206d2..41cd457bc3 100644 --- a/configs/ae350_rv32_spl_defconfig +++ b/configs/ae350_rv32_spl_defconfig @@ -33,6 +33,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -58,3 +59,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_spl_xip_defconfig b/configs/ae350_rv32_spl_xip_defconfig index f15ec301ce..954e2f2de7 100644 --- a/configs/ae350_rv32_spl_xip_defconfig +++ b/configs/ae350_rv32_spl_xip_defconfig @@ -34,6 +34,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -59,3 +60,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_xip_defconfig b/configs/ae350_rv32_xip_defconfig index c40eb043c5..95863595d2 100644 --- a/configs/ae350_rv32_xip_defconfig +++ b/configs/ae350_rv32_xip_defconfig @@ -24,6 +24,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -50,3 +51,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_defconfig b/configs/ae350_rv64_defconfig index 7ae938aeb2..988214285a 100644 --- a/configs/ae350_rv64_defconfig +++ b/configs/ae350_rv64_defconfig @@ -23,6 +23,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -49,3 +50,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_spl_defconfig b/configs/ae350_rv64_spl_defconfig index 68ac4325ab..e929320433 100644 --- a/configs/ae350_rv64_spl_defconfig +++ b/configs/ae350_rv64_spl_defconfig @@ -33,6 +33,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -58,3 +59,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_spl_xip_defconfig b/configs/ae350_rv64_spl_xip_defconfig index 839ca335d4..3f92643b07 100644 --- a/configs/ae350_rv64_spl_xip_defconfig +++ b/configs/ae350_rv64_spl_xip_defconfig @@ -34,6 +34,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -59,3 +60,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_xip_defconfig b/configs/ae350_rv64_xip_defconfig index 5432b6d6d7..835f020990 100644 ---
Re: [PATCH V4 1/2] drivers: watchdog: add andes atcwdt200 support
On 1/24/24 07:21, Randolph wrote:
This patch adds an implementation of the Andes watchdog ATCWDT200 driver.
Signed-off-by: CL Wang
Signed-off-by: Randolph
Reviewed-by: Leo Yu-Chi Liang
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
drivers/watchdog/Kconfig | 6 +
drivers/watchdog/Makefile| 1 +
drivers/watchdog/atcwdt200_wdt.c | 220 +++
3 files changed, 227 insertions(+)
create mode 100644 drivers/watchdog/atcwdt200_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 569726119c..8318fd77a3 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -130,6 +130,12 @@ config WDT_AT91
Select this to enable Microchip watchdog timer, which can be found on
some AT91 devices.
+config WDT_ATCWDT200
+ bool "Andes watchdog timer support"
+ depends on WDT
+ help
+ Select this to enable Andes ATCWDT200 watchdog timer
+
config WDT_BCM6345
bool "BCM6345 watchdog timer support"
depends on WDT && (ARCH_BMIPS || BCM6856 || \
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5520d3d9ae..7b39adcf0f 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_WDT_ARM_SMC) += arm_smc_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_ATCWDT200) += atcwdt200_wdt.o
obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
diff --git a/drivers/watchdog/atcwdt200_wdt.c b/drivers/watchdog/atcwdt200_wdt.c
new file mode 100644
index 00..a29b42d607
--- /dev/null
+++ b/drivers/watchdog/atcwdt200_wdt.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Andes Technology Corporation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define NODE_NOT_FOUND 0x
+
+#define WDT_WP_MAGIC 0x5aa5
+#define WDT_RESTART_MAGIC 0xcafe
+
+/* Control Register */
+#define REG_WDT_ID 0x00
+#define REG_WDT_CFG0x10
+#define REG_WDT_RS 0x14
+#define REG_WDT_WE 0x18
+#define REG_WDT_STA0x1C
+
+#define RST_TIME_OFF 8
+#define RST_TIME_MSK (0x7 << RST_TIME_OFF)
+#define RST_CLK_128(0 << RST_TIME_OFF)
+#define RST_CLK_256(1 << RST_TIME_OFF)
+#define RST_CLK_512(2 << RST_TIME_OFF)
+#define RST_CLK_1024 (3 << RST_TIME_OFF)
+#define INT_TIME_OFF 4
+#define INT_TIME_MSK (0xf << INT_TIME_OFF)
+#define INT_CLK_2_6(0 << INT_TIME_OFF) /* clk period*2^6 */
+#define INT_CLK_2_8(1 << INT_TIME_OFF) /* clk period*2^8 */
+#define INT_CLK_2_10 (2 << INT_TIME_OFF) /* clk period*2^10 */
+#define INT_CLK_2_11 (3 << INT_TIME_OFF) /* clk period*2^11 */
+#define INT_CLK_2_12 (4 << INT_TIME_OFF) /* clk period*2^12 */
+#define INT_CLK_2_13 (5 << INT_TIME_OFF) /* clk period*2^13 */
+#define INT_CLK_2_14 (6 << INT_TIME_OFF) /* clk period*2^14 */
+#define INT_CLK_2_15 (7 << INT_TIME_OFF) /* clk period*2^15 */
+#define INT_CLK_2_17 (8 << INT_TIME_OFF) /* clk period*2^17 */
+#define INT_CLK_2_19 (9 << INT_TIME_OFF) /* clk period*2^19 */
+#define INT_CLK_2_21 (10 << INT_TIME_OFF) /* clk period*2^21 */
+#define INT_CLK_2_23 (11 << INT_TIME_OFF) /* clk period*2^23 */
+#define INT_CLK_2_25 (12 << INT_TIME_OFF) /* clk period*2^25 */
+#define INT_CLK_2_27 (13 << INT_TIME_OFF) /* clk period*2^27 */
+#define INT_CLK_2_29 (14 << INT_TIME_OFF) /* clk period*2^29 */
+#define INT_CLK_2_31 (15 << INT_TIME_OFF) /* clk period*2^31 */
+#define INT_CLK_MIN0x0
+#define INT_CLK_MAX_16B0x7
+#define INT_CLK_MAX_32B0xF
+#define RST_EN BIT(3)
+#define INT_EN BIT(2)
+#define CLK_PCLK BIT(1)
+#define WDT_EN BIT(0)
+#define INT_EXPIREDBIT(0)
+
+#define INT_TIME_ARRAY 16
+#define RST_TIME_ARRAY 8
+
+struct wdt_priv {
+ void __iomem *base;
+ u32 wdt_clk_src;
+ u32 clk_freq;
+ u8 max_clk;
+};
+
+static inline u8 atcwdt_get_2_power_of_n(u8 index, u8 type)
+{
+ const u8 div_int[INT_TIME_ARRAY] = {6, 8, 10, 11, 12, 13, 14, 15,
+ 17, 19, 21, 23, 25, 27, 29, 31};
+ const u8 div_rst[RST_TIME_ARRAY] = {7, 8, 9, 10, 11, 12, 13, 14};
+ const u8 *pdiv;
+
+ if (type == RST_TIME_ARRAY)
+ pdiv = div_rst;
+ else
+ pdiv = div_int;
+
+ if (index >= type)
+ index = type - 1;
+
+ return pdiv[index];
+}
+
+static u8 atcwdt_search_msb(u64 freq_ms, u8 type)
+{
+ u64 result;
+ u64 freq_sec;
+ u8 index;
+
+ freq_sec = freq_ms / 1000;
+ for (index = 0; index < type; index++) {
+
