Re: [EXT] Re: [PATCH] usb: ehci-hcd: Add IAA handshake for removing async QH
On 3/9/21 4:18 AM, Ye Li wrote: Hi Marek, Hi, [...] + 10 * 1000); /* 10ms timeout */ + if (ret < 0) + printf("EHCI fail timeout STS_IAA set\n"); Shouldn't there be some abort ^ if ret < 0 ? Also, add the return value into the printf, it is useful for debugging. I don't think need to abort anything when ret < 0. The ret value is very simple in handshake, when ret < 0, it must be -1. Actually the codes refer the ehci_enable_async for the usage of handshake. If the handshake timed out, that indicates a problem and that problem shouldn't be ignored, but rather propagated, no ? Maybe the entire ehci transfer should be aborted ? [...] + ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA); + + return ret; +} Is this a bugfix for this release or is this for next release ? We're in rc3 already, so I would suggest to be careful. It is ok to add the fix for next release. From our tests, the issue is not very easy to reproduce by just using usb read/write. In SCT, generally we need to run about 1 hour to see the issue. Can you add details on how to reproduce the issue into the commit message ? That would be highly helpful.
Re: [EXT] Re: [PATCH] usb: ehci-hcd: Add IAA handshake for removing async QH
Hi Marek, On Tue, 2021-03-09 at 09:08 +0100, Marek Vasut wrote: > Caution: EXT Email > > On 3/9/21 4:18 AM, Ye Li wrote: > > > > Hi Marek, > Hi, > > [...] > > > > > > > > > > > > > > > > > > + 10 * 1000); /* 10ms timeout */ > > > > + if (ret < 0) > > > > + printf("EHCI fail timeout STS_IAA set\n"); > > > Shouldn't there be some abort ^ if ret < 0 ? > > > Also, add the return value into the printf, it is useful for > > > debugging. > > I don't think need to abort anything when ret < 0. The ret value is > > very simple in handshake, when ret < 0, it must be -1. > > Actually the codes refer the ehci_enable_async for the usage of > > handshake. > If the handshake timed out, that indicates a problem and that problem > shouldn't be ignored, but rather propagated, no ? Maybe the entire > ehci > transfer should be aborted ? > I supposed the problem means QH does not advance, so next submit of async transfer will have QTD timeout. But it is ok to abort transfer as the error handling. > [...] > > > > > > > > > > > > > > > > > > + ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA); > > > > + > > > > + return ret; > > > > +} > > > Is this a bugfix for this release or is this for next release ? > > > We're in rc3 already, so I would suggest to be careful. > > It is ok to add the fix for next release. From our tests, the issue > > is > > not very easy to reproduce by just using usb read/write. In > > SCT, generally we need to run about 1 hour to see the issue. > Can you add details on how to reproduce the issue into the commit > message ? That would be highly helpful. ok. I will add more. Best regards, Ye Li
Re: [PATCH] disk: gpt: verify alternate LBA points to last usable LBA
Hi Heinrich, Am 08.03.2021 um 18:38 schrieb Heinrich Schuchardt: On 08.03.21 17:07, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier The gpt command require the GPT backup header at the standard location at the end of the device.Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. If there is a bug in the gpt command, please, fix it instead of introducing constraints that don't exist in the UEFI specification. The constraints already exists because the command only supports backup header at the end. At the moment the command blindly check the backup header at the end even if the primary header points to an other position. The UEFI specification has: "The backup GPT Partition Entry Array must be located after the Last Usable LBA and end before the backup GPT Header." A lot of tools complain a backup head outside of the last LBA and move the header with the next write. And of course the backup GPT header has to reside within the disk size. There may be good reasons not to place the GPT header on the last LBA. E.g. if the last sector is defective. At the moment the command only supports a backup header at the end but doesn't check if the primary header points to the last LBA. Signed-off-by: Stefan Herbrechtsmeier --- disk/part_efi.c | 9 + 1 file changed, 9 insertions(+) diff --git a/disk/part_efi.c b/disk/part_efi.c index e5636ea7e6..0fb7ff0b6b 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -692,6 +692,15 @@ int gpt_verify_headers(struct blk_desc *dev_desc, gpt_header *gpt_head, /* Free pte before allocating again */ free(*gpt_pte); + /* +* Check that the alternate_lba entry points to the last LBA +*/ + if (le64_to_cpu(gpt_head->alternate_lba) != (dev_desc->lba - 1)) { This is wrong. You may check: le64_to_cpu(gpt_head->alternate_lba) < dev_desc->lba and AlternateLBA > LastUsableLBA + ceil(NumberOfPartitionEntries * SizeOfPartitionEntry / SizeOfLBA) Why you need this checks? Doesn't this belongs to the check of the gpt itself? + printf("%s: *** ERROR: Misplaced Backup GPT ***\n", + __func__); + return -1; + } + if (is_gpt_valid(dev_desc, (dev_desc->lba - 1), This seems to be one of the buggy lines. You must use the alternate_lba field here. find_valid_gpt() should be corrected, too. Okay, I will rework the verify command to support backup headers outside of the last LBA. But I need a command to check if the backup header is at the last LBA. Do you have any suggestion? gpt_head, gpt_pte) != 1) { printf("%s: *** ERROR: Invalid Backup GPT ***\n", Regards Stefan
bug report : /drivers/pci/pcie_layerscape_rc.c "pcie->ctrl used without being initialised"
Hi, I would like to report a bug I got, while updating my u-boot version. Configuration : CPU : NXP LS1043a u-boot version : v2020.10 (I didn't see a fix for this issue in the latest u-boot version) What was happening : Function "unsigned int ctrl_readl(struct ls_pcie *pcie, unsigned int offset)" in "/drivers/pci/pcie_layerscape.c" was leading to a panic due to a read at an incorrect address. What was wrong : The address to read at, is extracted from the DTB, in my case, the nodes 'pcie', name 'ctrl' from the 'reg-name' list. This is done in the function "static int ls_pcie_probe(struct udevice *dev)" in "/drivers/pci/pcie_layerscape_rc.c" In some case (mine at least), the DTB doesn't contain the name 'ctrl' in the list 'reg-names' for the pcie nodes, causing 'fdt_get_named_resource()' to return (-1). This (-1) avoid the variable 'pcie->ctrl' to be initialized. This variable is not directly declared but a pointer 'pcie' to a structure ls_pcie is declared instead. Because the value of 'pcie->ctrl' is not initialized, there is a non-zero random value inside that passes the test "if (!pcie->ctrl)" and leads to the panic while given to the ctrl_read() as address to read. How I fixed it : Initialize the value of "pcie->ctrl" to NULL at the beginning of the function ls_pcie_probe() This make the check "if (!pcie->ctrl)" to fail and the variable "pcie->ctrl" is then initialized. How to reproduce it : Not sure... We load a FIT image containing a kernel, ramdisk and a DTB from an NOR memory through a QSPI interface. The checksum are OK. Then, we boot from it using the command 'bootm'. Once the FIT element are loaded, some checks (link) are done on the PCIe and the issue happens here. But, If I start another firmware, using the same DTB, from an eMMC memory. I have no issue at all, "pcie->ctrl" is initialized to NULL directly without need of a fix. Let me know if you want more information. Mit freundlichen Grüßen Florian Manoël Siemens AG Digital Industries Process Automation DI PA DCP R&D 2 Östliche Rheinbrückenstr. 50 76187 Karlsruhe, Deutschland Tel.: +49 721 667-20051 mailto:florian.man...@siemens.com www.siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
Re: [EXT] Re: [PATCH] usb: ehci-hcd: Add IAA handshake for removing async QH
On 3/9/21 10:32 AM, Ye Li wrote: Hi Marek, Hi, [...] + 10 * 1000); /* 10ms timeout */ + if (ret < 0) + printf("EHCI fail timeout STS_IAA set\n"); Shouldn't there be some abort ^ if ret < 0 ? Also, add the return value into the printf, it is useful for debugging. I don't think need to abort anything when ret < 0. The ret value is very simple in handshake, when ret < 0, it must be -1. Actually the codes refer the ehci_enable_async for the usage of handshake. If the handshake timed out, that indicates a problem and that problem shouldn't be ignored, but rather propagated, no ? Maybe the entire ehci transfer should be aborted ? I supposed the problem means QH does not advance, so next submit of async transfer will have QTD timeout. But it is ok to abort transfer as the error handling. If this is an error which would always cause subsequent error, abort here already. + ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA); + + return ret; +} Is this a bugfix for this release or is this for next release ? We're in rc3 already, so I would suggest to be careful. It is ok to add the fix for next release. From our tests, the issue is not very easy to reproduce by just using usb read/write. In SCT, generally we need to run about 1 hour to see the issue. Can you add details on how to reproduce the issue into the commit message ? That would be highly helpful. ok. I will add more. Thank you
Re: [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
On Tue, 9 Mar 2021 11:42:08 +0800 Bin Meng wrote: > Hi Marek, > > On Tue, Mar 9, 2021 at 9:24 AM Bin Meng wrote: > > > > Hi Marek, > > > > On Mon, Mar 8, 2021 at 11:22 PM Marek Behún wrote: > > > > > > On Mon, 8 Mar 2021 22:30:17 +0800 > > > Bin Meng wrote: > > > > > > > Hi Marek, > > > > > > > > On Mon, Mar 8, 2021 at 9:24 PM Marek Behún wrote: > > > > > > > > > > On Mon, 8 Mar 2021 19:32:10 +0800 > > > > > Bin Meng wrote: > > > > > > > > > > > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun > > > > > > wrote: > > > > > > > > > > > > > > On Mon, 8 Mar 2021 18:44:58 +0800 > > > > > > > Bin Meng wrote: > > > > > > > > > > > > > > > Could you investigate why? > > > > > > > > > > > > > > I could, but I don't understand why exactly I should > > > > > > > - Linux is also using --whole-archive > > > > > > > - it is working > > > > > > > - I have other things I would like to work on > > > > > > > > > > > > > > Maybe you could look into this? :) > > > > > > > > > > > > Yes, I can look into this. I wonder if you already knew this which > > > > > > could save some time as this is a normal review process, asking > > > > > > for clarifications if something isn't clear. > > > > > > > > > > Bin, CI is failing without the --whole-archive option. > > > > > > > > > > What is interesting is that the binaries build successfully, but > > > > > testing them fails :) > > > > > > > > > > You can try this (with and without the --whole-archive options) > > > > > (note that this is without LTO) > > > > > make qemu_arm_defconfig > > > > > CROSS_COMPILE=arm-compiler- make -j8 > > > > > qemu-system-arm -M virt -nographic \ > > > > > -netdev user,id=net0,tftp=$(pwd) \ > > > > > -device e1000,netdev=net0 -device virtio-rng-pci \ > > > > > -bios u-boot.bin -serial mon:stdio > > > > > > > > > > With --whole-archive option this boots successfully into U-Boot, > > > > > without --whole-archive it just hangs. > > > > > > > > Thanks for reporting. My initnial build testing on qemu_arm_defconfig > > > > with this series succeeded but there are some warnings: > > > > > > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: > > > > lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to > > > > handle lto object > > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: > > > > examples/standalone/hello_world.o: plugin needed to handle lto object > > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o: > > > > plugin needed to handle lto object > > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry > > > > symbol hello_world; defaulting to 0c10 > > > > > > > > It looks we should update the make rules to remove "-flto" for these > > > > targets. > > > > > > > > Applying the following diff to remove --whole-archive, I got a build > > > > error: > > > > > > > > diff --git a/Makefile b/Makefile > > > > index 0f538270d7..127630e060 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@ > > > > $(LTO_FINAL_CFLAGS) $(c_flags) > > > > \ > > > > $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o > > > > $@ \ > > > > -T u-boot.lds $(u-boot-init) > > > > \ > > > > - -Wl,--start-group -Wl,--whole-archive > > > > \ > > > > + -Wl,--start-group > > > > \ > > > > $(u-boot-main) > > > > \ > > > > $(PLATFORM_LIBS) > > > > \ > > > > -Wl,--no-whole-archive -Wl,--end-group > > > > \ > > > > @@ -1790,9 +1790,9 @@ else > > > > quiet_cmd_u-boot__ ?= LD $@ > > > >cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ > > > > \ > > > > -T u-boot.lds $(u-boot-init) > > > > \ > > > > - --start-group --whole-archive > > > > \ > > > > + --start-group > > > > \ > > > > $(u-boot-main) > > > > \ > > > > - --no-whole-archive --end-group > > > > \ > > > > + --end-group > > > > \ > > > > $(PLATFORM_LIBS) -Map u-boot.map; > > > > \ > > > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) > > > > $@, true) endif > > > > > > > > LTO u-boot > > > > /opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: > > > > arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0': > > > > arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0' > > > > > > > > I am using a pre-built armv7 toolchain from > > > > https://toolchains.bootlin.com/ > > > > > > The > > > plugin needed to handle lto object > > > need another change in Makefiles, I will look into this. > > > > > > As for the __div0 availability, that happens when compiling with LTO > > > and no
Re: [PATCH 1/4] watchdog: Set/unset GD_FLG_WDT_READY flag in wdt_start()/wdt_stop()
On 05.03.21 22:36, Pali Rohár wrote: Watchdog is ready after successful call of ops->start() callback in wdt_start() function. And is stopped after successful call of ops->stop() callback in wdt_stop function. So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop() function. This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is running. And ensures that flag is also also when watchdog was started not only by initr_watchdog() call (e.g. by U-Boot 'wdt' command). Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/watchdog/wdt-uclass.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 28f7918c4673..3f707f61f74f 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -51,7 +51,6 @@ int initr_watchdog(void) } wdt_start(gd->watchdog_dev, timeout * 1000, 0); - gd->flags |= GD_FLG_WDT_READY; printf("WDT: Started with%s servicing (%ds timeout)\n", IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); @@ -61,21 +60,31 @@ int initr_watchdog(void) int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) { const struct wdt_ops *ops = device_get_ops(dev); + int ret; if (!ops->start) return -ENOSYS; - return ops->start(dev, timeout_ms, flags); + ret = ops->start(dev, timeout_ms, flags); + if (ret == 0) + gd->flags |= GD_FLG_WDT_READY; + + return ret; } int wdt_stop(struct udevice *dev) { const struct wdt_ops *ops = device_get_ops(dev); + int ret; if (!ops->stop) return -ENOSYS; - return ops->stop(dev); + ret = ops->stop(dev); + if (ret == 0) + gd->flags &= ~GD_FLG_WDT_READY; + + return ret; } int wdt_reset(struct udevice *dev) Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 2/4] watchdog: Show error message when initr_watchdog() cannot start watchdog
On 05.03.21 22:36, Pali Rohár wrote: Function wdt_start() may fail. So in initr_watchdog() function check return value of wdt_start() call and print error message when watchdog starting failed. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/watchdog/wdt-uclass.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 3f707f61f74f..7500b3ed90e3 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -27,6 +27,7 @@ static ulong reset_period = 1000; int initr_watchdog(void) { u32 timeout = WATCHDOG_TIMEOUT_SECS; + int ret; /* * Init watchdog: This will call the probe function of the @@ -50,7 +51,12 @@ int initr_watchdog(void) 4 * reset_period) / 4; } - wdt_start(gd->watchdog_dev, timeout * 1000, 0); + ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); + if (ret != 0) { + printf("WDT: Failed to start\n"); + return 0; + } + printf("WDT: Started with%s servicing (%ds timeout)\n", IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog
On 05.03.21 22:36, Pali Rohár wrote: In some cases it is useful to compile support for U-Boot command 'wdt' without starting HW watchdog in early U-Boot phase. For example when user Nitpicking: when "the" user want to start watchdog only on demand by some boot script. This change adds a new compile option WATCHDOG_AUTOSTART to control whether U-Boot should automatically start watchdog during init phase or not. start "the" watchdog This option is enabled by default as it was was default behavior prior as it was the default introducing this new change. When compiling U-Boot users can decide to turn this option off. Signed-off-by: Pali Rohár --- drivers/watchdog/Kconfig | 13 + drivers/watchdog/wdt-uclass.c | 7 +++ 2 files changed, 20 insertions(+) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 602ccbe41c00..aa76a8f2d239 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -9,6 +9,19 @@ config WATCHDOG this option if you want to service enabled watchdog by U-Boot. Disable this option if you want U-Boot to start watchdog but never service it. +config WATCHDOG_AUTOSTART + bool "Automatically start watchdog timer" + depends on WDT + default y + help + Automatically start watchdog timer and start servicing it during + init phase. Enabled by default. Disable this option if you want + to compile U-Boot with CONFIG_WDT support but do not want to + activate watchdog, like when CONFIG_WDT option is disabled. You + would be able to start watchdog manually by 'wdt' command. Useful + when you want to have support for 'wdt' command but do not want + to have watchdog enabled by default. + config WATCHDOG_TIMEOUT_MSECS int "Watchdog timeout in msec" default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6 diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 7500b3ed90e3..00a408bf5cc5 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -27,7 +27,9 @@ static ulong reset_period = 1000; int initr_watchdog(void) { u32 timeout = WATCHDOG_TIMEOUT_SECS; +#ifdef CONFIG_WATCHDOG_AUTOSTART int ret; +#endif Please don't add more #ifdef's if possible, see below... /* * Init watchdog: This will call the probe function of the @@ -51,6 +53,10 @@ int initr_watchdog(void) 4 * reset_period) / 4; } +#ifndef CONFIG_WATCHDOG_AUTOSTART + printf("WDT: Not starting\n"); + return 0; +#else ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); if (ret != 0) { printf("WDT: Failed to start\n"); @@ -61,6 +67,7 @@ int initr_watchdog(void) IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); return 0; +#endif Please use this instead here: if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) { ... Thanks, Stefan } int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 4/4] arm: mvebu: Espressobin: Enable watchdog support but do not start it
On 05.03.21 22:36, Pali Rohár wrote: Espressobin had disabled watchdog support (CONFIG_WDT) because older stable Linux kernel versions (which are used by current stable OpenWRT and Debian versions) do not have support for Armada 3700 watchdog driver. Therefore they are not able to periodically kick watchdog so Espressobin enter into boot loop. This change enable CONFIG_WDT, CONFIG_WDT_ARMADA_37XX and CONFIG_CMD_WDT options which add support for U-Boot 'wdt' command. And unset new CONFIG_WATCHDOG_AUTOSTART option which cause that watchdog is not automatically started by U-Boot during init phase, like when CONFIG_WDT option is not set at all. So with this change, U-Boot on Espressobin would have working 'wdt' command which can be used from boot scripts (e.g. for enabling watchdog prior new Linux booting kernel). But default behavior of watchdog status stays unchanged, U-Boot does not start watchdog on Espressobin during its init phase. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- configs/mvebu_espressobin-88f3720_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index c791f98dfea5..20aa21b06b3d 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -32,6 +32,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y @@ -88,5 +89,8 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ARMADA_37XX=y CONFIG_SHA1=y CONFIG_SHA256=y Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/2] board: gateworks: venice: fix gsc_get_dev
Hi Tim, On Mon, Mar 8, 2021 at 6:52 PM Tim Harvey wrote: > > use dm_i2c_probe instead of i2c_get_chip which appears to be more > reliable. > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
Re: [PATCH 2/2] board: gateworks: venice: increase CONFIG_SYS_SPL_MALLOC_SIZE
On Mon, Mar 8, 2021 at 6:52 PM Tim Harvey wrote: > > commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for loading > images")' > changed the way buffer allocation worked for SPL to a more flexible > method. > > For venice this caused breakage that is resolved by increasing the size > of CONFIG_SYS_SPL_MALLOC_SIZE as the current FIT slighly exceeds 512KiB. > > Additionally remove the unnecessary comment on CONFIG_SPL_BSS_MAX_SIZE > and CONFIG_SYS_SPL_MALLOC_SIZE as the size is obvious from the define. > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
[PATCH 00/16] TI/Cadence: Add Sierra/Torrent SERDES driver
Patch series adds Sierra and Torrent SERDES driver for the SERDES used in TI's K3 platforms. This SERDES is used by USB3, PCIe and Ethernet. This series is mostly an adaptation of drivers added in upstream Linux kernel. Alan Douglas (1): phy: cadence: Add driver for Sierra PHY Aswath Govindraju (7): dt-bindings: phy: Add definitions for additional phy types phy: cadence: Add driver for Torrent SERDES board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200 arm: dts: k3-j7200-main: Add DT node for torrent serdes arm: dts: k3-j7200-common-proc-board: Enable SERDES DT arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework Jean-Jacques Hiblot (3): drivers: reset: Handle gracefully NULL pointers phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC configs: j721e_evm_a72: Enable the drivers required for the USB3 support Kishon Vijay Abraham I (5): dm: core: Add helper to compare node names usb: cdns3: cdns3-ti: Fix clk_get_by_name() to get the correct name ARM: dts: k3-j721e: Add the entries required for USB3 support on USB0 env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY .../k3-j7200-common-proc-board-u-boot.dtsi| 12 + arch/arm/dts/k3-j7200-common-proc-board.dts | 23 + arch/arm/dts/k3-j7200-main.dtsi | 63 + .../k3-j721e-common-proc-board-u-boot.dtsi| 19 +- board/ti/j721e/evm.c | 34 +- configs/j7200_evm_a72_defconfig |9 +- configs/j721e_evm_a72_defconfig |6 + drivers/core/ofnode.c | 13 + drivers/phy/Kconfig |3 + drivers/phy/Makefile |2 + drivers/phy/cadence/Kconfig | 11 + drivers/phy/cadence/Makefile |2 + drivers/phy/cadence/phy-cadence-sierra.c | 757 + drivers/phy/cadence/phy-cadence-torrent.c | 2456 + drivers/phy/ti/Kconfig|9 + drivers/phy/ti/Makefile |1 + drivers/phy/ti/phy-j721e-wiz.c| 985 +++ drivers/reset/reset-uclass.c | 30 +- drivers/usb/cdns3/cdns3-ti.c |2 +- include/configs/j721e_evm.h | 16 +- include/dm/ofnode.h |9 + include/dt-bindings/phy/phy.h |1 + 22 files changed, 4445 insertions(+), 18 deletions(-) create mode 100644 drivers/phy/cadence/Kconfig create mode 100644 drivers/phy/cadence/Makefile create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c create mode 100644 drivers/phy/ti/Kconfig create mode 100644 drivers/phy/ti/Makefile create mode 100644 drivers/phy/ti/phy-j721e-wiz.c -- 2.17.1
[PATCH 01/16] dm: core: Add helper to compare node names
Add helper to compare node names. Signed-off-by: Kishon Vijay Abraham I --- drivers/core/ofnode.c | 13 + include/dm/ofnode.h | 9 + 2 files changed, 22 insertions(+) diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c index fa0bd2a9c4..4e196d680e 100644 --- a/drivers/core/ofnode.c +++ b/drivers/core/ofnode.c @@ -18,6 +18,19 @@ #include #include +bool ofnode_name_eq(ofnode node, const char *name) +{ + const char *node_name; + size_t len; + + assert(ofnode_valid(node)); + + node_name = ofnode_get_name(node); + len = strchrnul(node_name, '@') - node_name; + + return (strlen(name) == len) && (strncmp(node_name, name, len) == 0); +} + int ofnode_read_u32(ofnode node, const char *propname, u32 *outp) { return ofnode_read_u32_index(node, propname, 0, outp); diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h index 2c0597c407..86a139276b 100644 --- a/include/dm/ofnode.h +++ b/include/dm/ofnode.h @@ -231,6 +231,15 @@ static inline ofnode ofnode_root(void) return node; } +/** + * ofnode_name_eq() - Check if the node name is equivalent to a given name + * + * @node: valid node reference that has to be compared + * @name: name that has to be compared with the node name + * @return 1 if matches, 0 if it doesn't match + */ +bool ofnode_name_eq(ofnode node, const char *name); + /** * ofnode_read_u32() - Read a 32-bit integer from a property * -- 2.17.1
[PATCH 02/16] drivers: reset: Handle gracefully NULL pointers
From: Jean-Jacques Hiblot Prepare the way for a managed reset API by handling NULL pointers without crashing nor failing. Signed-off-by: Jean-Jacques Hiblot Signed-off-by: Vignesh Raghavendra Signed-off-by: Kishon Vijay Abraham I --- drivers/reset/reset-uclass.c | 30 +- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c index 071c389ca0..98304bc0ee 100644 --- a/drivers/reset/reset-uclass.c +++ b/drivers/reset/reset-uclass.c @@ -13,9 +13,12 @@ #include #include -static inline struct reset_ops *reset_dev_ops(struct udevice *dev) +struct reset_ops nop_reset_ops = { +}; + +static inline struct reset_ops *reset_dev_ops(struct reset_ctl *r) { - return (struct reset_ops *)dev->driver->ops; + return r ? (struct reset_ops *)r->dev->driver->ops : &nop_reset_ops; } static int reset_of_xlate_default(struct reset_ctl *reset_ctl, @@ -54,9 +57,10 @@ static int reset_get_by_index_tail(int ret, ofnode node, debug("%s %d\n", ofnode_get_name(args->node), args->args[0]); return ret; } - ops = reset_dev_ops(dev_reset); reset_ctl->dev = dev_reset; + ops = reset_dev_ops(reset_ctl); + if (ops->of_xlate) ret = ops->of_xlate(reset_ctl, args); else @@ -162,29 +166,29 @@ int reset_get_by_name(struct udevice *dev, const char *name, int reset_request(struct reset_ctl *reset_ctl) { - struct reset_ops *ops = reset_dev_ops(reset_ctl->dev); + struct reset_ops *ops = reset_dev_ops(reset_ctl); debug("%s(reset_ctl=%p)\n", __func__, reset_ctl); - return ops->request(reset_ctl); + return ops->request ? ops->request(reset_ctl) : 0; } int reset_free(struct reset_ctl *reset_ctl) { - struct reset_ops *ops = reset_dev_ops(reset_ctl->dev); + struct reset_ops *ops = reset_dev_ops(reset_ctl); debug("%s(reset_ctl=%p)\n", __func__, reset_ctl); - return ops->rfree(reset_ctl); + return ops->rfree ? ops->rfree(reset_ctl) : 0; } int reset_assert(struct reset_ctl *reset_ctl) { - struct reset_ops *ops = reset_dev_ops(reset_ctl->dev); + struct reset_ops *ops = reset_dev_ops(reset_ctl); debug("%s(reset_ctl=%p)\n", __func__, reset_ctl); - return ops->rst_assert(reset_ctl); + return ops->rst_assert ? ops->rst_assert(reset_ctl) : 0; } int reset_assert_bulk(struct reset_ctl_bulk *bulk) @@ -202,11 +206,11 @@ int reset_assert_bulk(struct reset_ctl_bulk *bulk) int reset_deassert(struct reset_ctl *reset_ctl) { - struct reset_ops *ops = reset_dev_ops(reset_ctl->dev); + struct reset_ops *ops = reset_dev_ops(reset_ctl); debug("%s(reset_ctl=%p)\n", __func__, reset_ctl); - return ops->rst_deassert(reset_ctl); + return ops->rst_deassert ? ops->rst_deassert(reset_ctl) : 0; } int reset_deassert_bulk(struct reset_ctl_bulk *bulk) @@ -224,11 +228,11 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk) int reset_status(struct reset_ctl *reset_ctl) { - struct reset_ops *ops = reset_dev_ops(reset_ctl->dev); + struct reset_ops *ops = reset_dev_ops(reset_ctl); debug("%s(reset_ctl=%p)\n", __func__, reset_ctl); - return ops->rst_status(reset_ctl); + return ops->rst_status ? ops->rst_status(reset_ctl) : 0; } int reset_release_all(struct reset_ctl *reset_ctl, int count) -- 2.17.1
[PATCH 03/16] dt-bindings: phy: Add definitions for additional phy types
From: Aswath Govindraju Add definitions for additional phy types that's used specifically for Torrent SERDES. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- include/dt-bindings/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h index 7e657da454..d3714edd4b 100644 --- a/include/dt-bindings/phy/phy.h +++ b/include/dt-bindings/phy/phy.h @@ -19,5 +19,6 @@ #define PHY_TYPE_DP6 #define PHY_TYPE_XPCS 7 #define PHY_TYPE_SGMII 8 +#define PHY_TYPE_QSGMII9 #endif /* _DT_BINDINGS_PHY */ -- 2.17.1
[PATCH 04/16] phy: cadence: Add driver for Sierra PHY
From: Alan Douglas Add a Sierra PHY driver with PCIe and USB support. This driver is a port from the mainline linux driver. The PHY has multiple lanes, which can be configured into groups, and a generic PHY device is created for each group. There are two resets controlling the overall PHY block, one to enable the APB interface for programming registers, and another to enable the PHY itself. Additionally there are resets for each PHY lane. The PHY can be configured in hardware to read register settings from ROM, or they can be written by the driver. The sequence of operation on startup is to enable the APB bus, write the PHY registers (if required) for each lane group, and then enable the PHY. Each group of lanes can then be individually controlled using the power_on()/ power_off() function for that generic PHY One difference with the linux driver is that the PHY is always reset after it is powered-on. This is because role switching is not supported in u-boot and the cable orientation is handled by the PHY reset. Signed-off-by: Jean-Jacques Hiblot Signed-off-by: Alan Douglas Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Vignesh Raghavendra --- drivers/phy/Kconfig | 2 + drivers/phy/Makefile | 1 + drivers/phy/cadence/Kconfig | 5 + drivers/phy/cadence/Makefile | 1 + drivers/phy/cadence/phy-cadence-sierra.c | 757 +++ 5 files changed, 766 insertions(+) create mode 100644 drivers/phy/cadence/Kconfig create mode 100644 drivers/phy/cadence/Makefile create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 008186a10d..9208e430a6 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -269,4 +269,6 @@ config PHY_MTK_TPHY so you can easily distinguish them by banks layout. source "drivers/phy/rockchip/Kconfig" +source "drivers/phy/cadence/Kconfig" + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 3c4a673a83..4736c5eadb 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -31,3 +31,4 @@ obj-$(CONFIG_MT7620_USB_PHY) += mt7620-usb-phy.o obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o +obj-y += cadence/ diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig new file mode 100644 index 00..18a04819f5 --- /dev/null +++ b/drivers/phy/cadence/Kconfig @@ -0,0 +1,5 @@ +config PHY_CADENCE_SIERRA + tristate "Cadence Sierra PHY Driver" + depends on DM_RESET + help + Enable this to support the Cadence Sierra PHY driver diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile new file mode 100644 index 00..d57856152a --- /dev/null +++ b/drivers/phy/cadence/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c new file mode 100644 index 00..66c671aded --- /dev/null +++ b/drivers/phy/cadence/phy-cadence-sierra.c @@ -0,0 +1,757 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Cadence Sierra PHY Driver + * + * Based on the linux driver provided by Cadence + * + * Copyright (c) 2018 Cadence Design Systems + * Author: Alan Douglas + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + * Jean-Jacques Hiblot + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* PHY register offsets */ +#define SIERRA_COMMON_CDB_OFFSET 0x0 +#define SIERRA_MACRO_ID_REG0x0 +#define SIERRA_CMN_PLLLC_MODE_PREG 0x48 +#define SIERRA_CMN_PLLLC_LF_COEFF_MODE1_PREG 0x49 +#define SIERRA_CMN_PLLLC_LF_COEFF_MODE0_PREG 0x4A +#define SIERRA_CMN_PLLLC_LOCK_CNTSTART_PREG0x4B +#define SIERRA_CMN_PLLLC_BWCAL_MODE1_PREG 0x4F +#define SIERRA_CMN_PLLLC_BWCAL_MODE0_PREG 0x50 +#define SIERRA_CMN_PLLLC_SS_TIME_STEPSIZE_MODE_PREG0x62 + +#define SIERRA_LANE_CDB_OFFSET(ln, offset) \ + (0x4000 + ((ln) * (0x800 >> (2 - (offset) + +#define SIERRA_DET_STANDEC_A_PREG 0x000 +#define SIERRA_DET_STANDEC_B_PREG 0x001 +#define SIERRA_DET_STANDEC_C_PREG 0x002 +#define SIERRA_DET_STANDEC_D_PREG 0x003 +#define SIERRA_DET_STANDEC_E_PREG 0x004 +#define SIERRA_PSM_LANECAL_DLY_A1_RESETS_PREG 0x008 +#define SIERRA_PSM_A0IN_TMR_PREG 0x009 +#define SIERRA_PSM_DIAG_PREG 0x015 +#define SIERRA_PSC_TX_A0_PREG 0x028 +#define SIERRA_PSC_TX_A1_PREG
[PATCH 07/16] usb: cdns3: cdns3-ti: Fix clk_get_by_name() to get the correct name
Upstream device tree got updated to use clock name as "ref" instead of "usb2_refclk". Fix cdns3-ti.c to use the correct name. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/cdns3/cdns3-ti.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c index 7b205c5656..43171678ee 100644 --- a/drivers/usb/cdns3/cdns3-ti.c +++ b/drivers/usb/cdns3/cdns3-ti.c @@ -101,7 +101,7 @@ static int cdns_ti_probe(struct udevice *dev) if (!data->usbss) return -EINVAL; - ret = clk_get_by_name(dev, "usb2_refclk", &usb2_refclk); + ret = clk_get_by_name(dev, "ref", &usb2_refclk); if (ret) { dev_err(dev, "Failed to get usb2_refclk\n"); return ret; -- 2.17.1
[PATCH 05/16] phy: cadence: Add driver for Torrent SERDES
From: Aswath Govindraju Add driver for Torrent SERDES. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/cadence/Kconfig |6 + drivers/phy/cadence/Makefile |1 + drivers/phy/cadence/phy-cadence-torrent.c | 2456 + 3 files changed, 2463 insertions(+) create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig index 18a04819f5..549ddbf504 100644 --- a/drivers/phy/cadence/Kconfig +++ b/drivers/phy/cadence/Kconfig @@ -3,3 +3,9 @@ config PHY_CADENCE_SIERRA depends on DM_RESET help Enable this to support the Cadence Sierra PHY driver + +config PHY_CADENCE_TORRENT + tristate "Cadence Torrent PHY Driver" + depends on DM_RESET + help + Enable this to support the Cadence Torrent PHY driver diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile index d57856152a..af63b32d9f 100644 --- a/drivers/phy/cadence/Makefile +++ b/drivers/phy/cadence/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o +obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cadence/phy-cadence-torrent.c new file mode 100644 index 00..daaefdd570 --- /dev/null +++ b/drivers/phy/cadence/phy-cadence-torrent.c @@ -0,0 +1,2456 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Cadence Torrent SD0801 PHY driver. + * + * Based on the linux driver provided by Cadence + * + * Copyright (c) 2018 Cadence Design Systems + * + * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/ + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REF_CLK_19_2MHz1920 +#define REF_CLK_25MHz 2500 + +#define MAX_NUM_LANES 4 +#define DEFAULT_MAX_BIT_RATE 8100 /* in Mbps*/ + +#define NUM_SSC_MODE 3 +#define NUM_PHY_TYPE 6 + +#define POLL_TIMEOUT_US5000 +#define PLL_LOCK_TIMEOUT 10 + +#define TORRENT_COMMON_CDB_OFFSET 0x0 + +#define TORRENT_TX_LANE_CDB_OFFSET(ln, block_offset, reg_offset) \ + ((0x4000 << (block_offset)) + \ + (((ln) << 9) << (reg_offset))) +#define TORRENT_RX_LANE_CDB_OFFSET(ln, block_offset, reg_offset) \ + ((0x8000 << (block_offset)) + \ + (((ln) << 9) << (reg_offset))) + +#define TORRENT_PHY_PCS_COMMON_OFFSET(block_offset)\ + (0xC000 << (block_offset)) + +#define TORRENT_PHY_PMA_COMMON_OFFSET(block_offset)\ + (0xE000 << (block_offset)) + +/* + * register offsets from SD0801 PHY register block base (i.e MHDP + * register base + 0x50) + */ +#define CMN_SSM_BANDGAP_TMR0x0021U +#define CMN_SSM_BIAS_TMR 0x0022U +#define CMN_PLLSM0_PLLPRE_TMR 0x002AU +#define CMN_PLLSM0_PLLLOCK_TMR 0x002CU +#define CMN_PLLSM1_PLLPRE_TMR 0x0032U +#define CMN_PLLSM1_PLLLOCK_TMR 0x0034U +#define CMN_CDIAG_CDB_PWRI_OVRD0x0041U +#define CMN_CDIAG_XCVRC_PWRI_OVRD 0x0047U +#define CMN_BGCAL_INIT_TMR 0x0064U +#define CMN_BGCAL_ITER_TMR 0x0065U +#define CMN_IBCAL_INIT_TMR 0x0074U +#define CMN_PLL0_VCOCAL_TCTRL 0x0082U +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084U +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085U +#define CMN_PLL0_VCOCAL_REFTIM_START 0x0086U +#define CMN_PLL0_VCOCAL_PLLCNT_START 0x0088U +#define CMN_PLL0_INTDIV_M0 0x0090U +#define CMN_PLL0_FRACDIVL_M0 0x0091U +#define CMN_PLL0_FRACDIVH_M0 0x0092U +#define CMN_PLL0_HIGH_THR_M0 0x0093U +#define CMN_PLL0_DSM_DIAG_M0 0x0094U +#define CMN_PLL0_SS_CTRL1_M0 0x0098U +#define CMN_PLL0_SS_CTRL2_M0 0x0099U +#define CMN_PLL0_SS_CTRL3_M0 0x009AU +#define CMN_PLL0_SS_CTRL4_M0 0x009BU +#define CMN_PLL0_LOCK_REFCNT_START 0x009CU +#define CMN_PLL0_LOCK_PLLCNT_START 0x009EU +#define CMN_PLL0_LOCK_PLLCNT_THR 0x009FU +#define CMN_PLL0_INTDIV_M1 0x00A0U +#define CMN_PLL0_FRACDIVH_M1 0x00A2U +#define CMN_PLL0_HIGH_THR_M1 0x00A3U +#define CMN_PLL0_DSM_DIAG_M1 0x00A4U +#define CMN_PLL0_SS_CTRL1_M1 0x00A8U +#define CMN_PLL0_SS_CTRL2_M1 0x00A9U +#define CMN_PLL0_SS_CTRL3_M1 0x00AAU +#define CMN_PLL0_SS_CTRL4_M1 0x00ABU +#define CMN_PLL1_VCOCAL_TCTRL 0x00C2U +#define CMN_PLL1_VCOCAL_INIT_TMR 0x00C4U +#define CMN_PLL1_VCOCAL_ITER_TMR 0x00C5U +#define CMN_PLL1_VCOCAL_REFTIM_START 0x00C6U +#def
[PATCH 06/16] phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC
From: Jean-Jacques Hiblot Add support for WIZ module present in TI's J721E SoC. WIZ is a SERDES wrapper used to configure some of the input signals to the SERDES. It is used with both Sierra(16G) and Torrent(10G) SERDES. This driver configures three clock selects (pll0, pll1, dig) and supports resets for each of the lanes. This is an adaptation of the linux driver. Signed-off-by: Jean-Jacques Hiblot Signed-off-by: Vignesh Raghavendra Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/Kconfig| 1 + drivers/phy/Makefile | 1 + drivers/phy/ti/Kconfig | 9 + drivers/phy/ti/Makefile| 1 + drivers/phy/ti/phy-j721e-wiz.c | 985 + 5 files changed, 997 insertions(+) create mode 100644 drivers/phy/ti/Kconfig create mode 100644 drivers/phy/ti/Makefile create mode 100644 drivers/phy/ti/phy-j721e-wiz.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 9208e430a6..7821161e3c 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -270,5 +270,6 @@ config PHY_MTK_TPHY source "drivers/phy/rockchip/Kconfig" source "drivers/phy/cadence/Kconfig" +source "drivers/phy/ti/Kconfig" endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 4736c5eadb..2efaa8827b 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -32,3 +32,4 @@ obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o obj-y += cadence/ +obj-y += ti/ diff --git a/drivers/phy/ti/Kconfig b/drivers/phy/ti/Kconfig new file mode 100644 index 00..111085f235 --- /dev/null +++ b/drivers/phy/ti/Kconfig @@ -0,0 +1,9 @@ +config PHY_J721E_WIZ + tristate "TI J721E WIZ (SERDES Wrapper) support" + depends on ARCH_K3 + help + This option enables support for WIZ module present in TI's J721E + SoC. WIZ is a serdes wrapper used to configure some of the input + signals to the SERDES (Sierra/Torrent). This driver configures + three clock selects (pll0, pll1, dig) and resets for each of the + lanes. diff --git a/drivers/phy/ti/Makefile b/drivers/phy/ti/Makefile new file mode 100644 index 00..873ddbf036 --- /dev/null +++ b/drivers/phy/ti/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_$(SPL_)PHY_J721E_WIZ) += phy-j721e-wiz.o diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c new file mode 100644 index 00..39384f87b8 --- /dev/null +++ b/drivers/phy/ti/phy-j721e-wiz.c @@ -0,0 +1,985 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/ + * Jean-Jacques Hiblot + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define WIZ_MAX_LANES 4 +#define WIZ_MUX_NUM_CLOCKS 3 +#define WIZ_DIV_NUM_CLOCKS_16G 2 +#define WIZ_DIV_NUM_CLOCKS_10G 1 + +#define WIZ_SERDES_CTRL0x404 +#define WIZ_SERDES_TOP_CTRL0x408 +#define WIZ_SERDES_RST 0x40c +#define WIZ_SERDES_TYPEC 0x410 +#define WIZ_LANECTL(n) (0x480 + (0x40 * (n))) +#define WIZ_LANEDIV(n) (0x484 + (0x40 * (n))) + +#define WIZ_MAX_LANES 4 +#define WIZ_MUX_NUM_CLOCKS 3 +#define WIZ_DIV_NUM_CLOCKS_16G 2 +#define WIZ_DIV_NUM_CLOCKS_10G 1 + +#define WIZ_SERDES_TYPEC_LN10_SWAP BIT(30) + +enum wiz_lane_standard_mode { + LANE_MODE_GEN1, + LANE_MODE_GEN2, + LANE_MODE_GEN3, + LANE_MODE_GEN4, +}; + +enum wiz_refclk_mux_sel { + PLL0_REFCLK, + PLL1_REFCLK, + REFCLK_DIG, +}; + +enum wiz_refclk_div_sel { + CMN_REFCLK, + CMN_REFCLK1, +}; + +static const struct reg_field por_en = REG_FIELD(WIZ_SERDES_CTRL, 31, 31); +static const struct reg_field phy_reset_n = REG_FIELD(WIZ_SERDES_RST, 31, 31); +static const struct reg_field pll1_refclk_mux_sel = + REG_FIELD(WIZ_SERDES_RST, 29, 29); +static const struct reg_field pll0_refclk_mux_sel = + REG_FIELD(WIZ_SERDES_RST, 28, 28); +static const struct reg_field refclk_dig_sel_16g = + REG_FIELD(WIZ_SERDES_RST, 24, 25); +static const struct reg_field refclk_dig_sel_10g = + REG_FIELD(WIZ_SERDES_RST, 24, 24); +static const struct reg_field pma_cmn_refclk_int_mode = + REG_FIELD(WIZ_SERDES_TOP_CTRL, 28, 29); +static const struct reg_field pma_cmn_refclk_mode = + REG_FIELD(WIZ_SERDES_TOP_CTRL, 30, 31); +static const struct reg_field pma_cmn_refclk_dig_div = + REG_FIELD(WIZ_SERDES_TOP_CTRL, 26, 27); +static const struct reg_field pma_cmn_refclk1_dig_div = + REG_FIELD(WIZ_SERDES_TOP_CTRL, 24, 25); + +static const struct reg_field p_enable[WIZ_MAX_LAN
[PATCH 08/16] board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200
From: Aswath Govindraju Add support for probing and configuring Torrent serdes on J7200. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- board/ti/j721e/evm.c | 34 +- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c index b9a9f19552..580f13c3ab 100644 --- a/board/ti/j721e/evm.c +++ b/board/ti/j721e/evm.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include @@ -29,7 +30,8 @@ #define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \ board_ti_k3_is("J721EX-PM2-SOM")) -#define board_is_j7200_som() board_ti_k3_is("J7200X-PM1-SOM") +#define board_is_j7200_som() (board_ti_k3_is("J7200X-PM1-SOM") || \ +board_ti_k3_is("J7200X-PM2-SOM")) /* Max number of MAC addresses that are parsed/processed per daughter card */ #define DAUGHTER_CARD_NO_OF_MAC_ADDR 8 @@ -384,6 +386,33 @@ static int probe_daughtercards(void) } #endif +void configure_serdes_torrent(void) +{ + struct udevice *dev; + struct phy serdes; + int ret; + + if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT)) + return; + + ret = uclass_get_device_by_driver(UCLASS_PHY, + DM_DRIVER_GET(torrent_phy_provider), + &dev); + if (ret) + printf("Torrent init failed:%d\n", ret); + + serdes.dev = dev; + serdes.id = 0; + + ret = generic_phy_init(&serdes); + if (ret) + printf("phy_init failed!!\n"); + + ret = generic_phy_power_on(&serdes); + if (ret) + printf("phy_power_on failed !!\n"); +} + int board_late_init(void) { if (IS_ENABLED(CONFIG_TI_I2C_BOARD_DETECT)) { @@ -394,6 +423,9 @@ int board_late_init(void) probe_daughtercards(); } + if (board_is_j7200_som()) + configure_serdes_torrent(); + return 0; } -- 2.17.1
[PATCH 09/16] ARM: dts: k3-j721e: Add the entries required for USB3 support on USB0
Partially sync with Linux's dts to add the entries required for USB3 support on USB0. Note that the default mode is still "peripheral" not "host". USB3 is supported only for the host mode. Signed-off-by: Jean-Jacques Hiblot Signed-off-by: Vignesh Raghavendra Signed-off-by: Kishon Vijay Abraham I --- .../k3-j721e-common-proc-board-u-boot.dtsi| 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi index 3384ed9f3a..3b2e40c13d 100644 --- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi +++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi @@ -115,13 +115,17 @@ u-boot,dm-spl; }; +&wiz3_pll1_refclk { + assigned-clocks = <&wiz3_pll1_refclk>, <&wiz3_pll0_refclk>; + assigned-clock-parents = <&k3_clks 295 0>, <&k3_clks 295 9>; +}; + &main_usbss0_pins_default { u-boot,dm-spl; }; &usbss0 { u-boot,dm-spl; - ti,usb2-only; }; &usb0 { @@ -193,3 +197,16 @@ &mcu_fss0_ospi1_pins_default { u-boot,dm-spl; }; + +&wiz3_pll1_refclk { + assigned-clocks = <&wiz3_pll1_refclk>, <&wiz3_pll0_refclk>; + assigned-clock-parents = <&k3_clks 295 0>, <&k3_clks 295 9>; +}; + +&serdes_ln_ctrl { + u-boot,mux-autoprobe; +}; + +&usb_serdes_mux { + u-boot,mux-autoprobe; +}; -- 2.17.1
[PATCH 10/16] arm: dts: k3-j7200-main: Add DT node for torrent serdes
From: Aswath Govindraju Add DT node for torrent serdes. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- arch/arm/dts/k3-j7200-main.dtsi | 63 + 1 file changed, 63 insertions(+) diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi index 1131464075..138702cf9d 100644 --- a/arch/arm/dts/k3-j7200-main.dtsi +++ b/arch/arm/dts/k3-j7200-main.dtsi @@ -5,6 +5,13 @@ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/ */ +/ { + serdes_refclk: serdes-refclk { + #clock-cells = <0>; + compatible = "fixed-clock"; + }; +}; + &cbass_main { msmc_ram: sram@7000 { compatible = "mmio-sram"; @@ -554,6 +561,62 @@ clock-names = "gpio"; }; + serdes_wiz0: wiz@506 { + compatible = "ti,j721e-wiz-10g"; + #address-cells = <1>; + #size-cells = <1>; + power-domains = <&k3_pds 292 TI_SCI_PD_EXCLUSIVE>; + clocks = <&k3_clks 292 11>, <&k3_clks 292 85>, <&serdes_refclk>; + clock-names = "fck", "core_ref_clk", "ext_ref_clk"; + num-lanes = <4>; + #reset-cells = <1>; + ranges = <0x506 0x0 0x506 0x1>; + + assigned-clocks = <&k3_clks 292 85>; + assigned-clock-parents = <&k3_clks 292 89>; + + wiz0_pll0_refclk: pll0-refclk { + clocks = <&k3_clks 292 85>, <&serdes_refclk>; + clock-output-names = "wiz0_pll0_refclk"; + #clock-cells = <0>; + assigned-clocks = <&wiz0_pll0_refclk>; + assigned-clock-parents = <&k3_clks 292 85>; + }; + + wiz0_pll1_refclk: pll1-refclk { + clocks = <&k3_clks 292 85>, <&serdes_refclk>; + clock-output-names = "wiz0_pll1_refclk"; + #clock-cells = <0>; + assigned-clocks = <&wiz0_pll1_refclk>; + assigned-clock-parents = <&k3_clks 292 85>; + }; + + wiz0_refclk_dig: refclk-dig { + clocks = <&k3_clks 292 85>, <&serdes_refclk>; + clock-output-names = "wiz0_refclk_dig"; + #clock-cells = <0>; + assigned-clocks = <&wiz0_refclk_dig>; + assigned-clock-parents = <&k3_clks 292 85>; + }; + + wiz0_cmn_refclk_dig_div: cmn-refclk-dig-div { + clocks = <&wiz0_refclk_dig>; + #clock-cells = <0>; + }; + + serdes0: serdes@506 { + compatible = "ti,j721e-serdes-10g"; + reg = <0x0506 0x0001>; + reg-names = "torrent_phy"; + resets = <&serdes_wiz0 0>; + reset-names = "torrent_reset"; + clocks = <&wiz0_pll0_refclk>; + clock-names = "refclk"; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + usbss0: cdns-usb@4104000 { compatible = "ti,j721e-usb"; reg = <0x00 0x4104000 0x00 0x100>; -- 2.17.1
[PATCH 11/16] arm: dts: k3-j7200-common-proc-board: Enable SERDES DT
From: Aswath Govindraju Add default lane function for torrent serdes. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- arch/arm/dts/k3-j7200-common-proc-board.dts | 23 + 1 file changed, 23 insertions(+) diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts b/arch/arm/dts/k3-j7200-common-proc-board.dts index 5120711d4f..f0440cda1a 100644 --- a/arch/arm/dts/k3-j7200-common-proc-board.dts +++ b/arch/arm/dts/k3-j7200-common-proc-board.dts @@ -9,6 +9,7 @@ #include #include #include +#include / { chosen { @@ -281,3 +282,25 @@ ti,adc-channels = <0 1 2 3 4 5 6 7>; }; }; + +&serdes_refclk { + clock-frequency = <1>; +}; + +&serdes0 { + serdes0_pcie_link: link@0 { + reg = <0>; + cdns,num-lanes = <2>; + #phy-cells = <0>; + cdns,phy-type = ; + resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>; + }; + + serdes0_qsgmii_link: link@1 { + reg = <2>; + cdns,num-lanes = <1>; + #phy-cells = <0>; + cdns,phy-type = ; + resets = <&serdes_wiz0 3>; + }; +}; -- 2.17.1
[PATCH 12/16] arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes
From: Aswath Govindraju Add u-boot tags for torrent serdes. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi index bd037be350..bfe1ef5409 100644 --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi @@ -160,3 +160,15 @@ &hbmc_mux { u-boot,dm-spl; }; + +&serdes_ln_ctrl { + u-boot,mux-autoprobe; +}; + +&usb_serdes_mux { + u-boot,mux-autoprobe; +}; + +&serdes0 { + u-boot,dm-spl; +}; -- 2.17.1
[PATCH 13/16] configs: j721e_evm_a72: Enable the drivers required for the USB3 support
From: Jean-Jacques Hiblot Enable the mmio mux driver, the J721E-wiz PHy driver and the cadence sierra phy driver. All of them are required for USB3 support Signed-off-by: Jean-Jacques Hiblot Signed-off-by: Vignesh Raghavendra Signed-off-by: Kishon Vijay Abraham I --- configs/j721e_evm_a72_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index e14005c39d..5b46f2d53f 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -136,9 +136,15 @@ CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y CONFIG_PHY_TI_DP83867=y +CONFIG_MULTIPLEXER=y +CONFIG_MUX_MMIO=y CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y CONFIG_TI_AM65_CPSW_NUSS=y +CONFIG_PHY=y +CONFIG_SPL_PHY=y +CONFIG_PHY_CADENCE_SIERRA=y +CONFIG_PHY_J721E_WIZ=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y -- 2.17.1
[PATCH 14/16] configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework
From: Aswath Govindraju Add config for torrent serdes and common clock framework. Signed-off-by: Aswath Govindraju Signed-off-by: Kishon Vijay Abraham I --- configs/j7200_evm_a72_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig index 162bcc8753..bf78b36d22 100644 --- a/configs/j7200_evm_a72_defconfig +++ b/configs/j7200_evm_a72_defconfig @@ -96,6 +96,7 @@ CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y +CONFIG_CLK_CCF=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y CONFIG_DFU_SF=y @@ -138,9 +139,15 @@ CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y +CONFIG_MULTIPLEXER=y +CONFIG_MUX_MMIO=y CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y CONFIG_TI_AM65_CPSW_NUSS=y +CONFIG_PHY=y +CONFIG_SPL_PHY=y +CONFIG_PHY_CADENCE_TORRENT=y +CONFIG_PHY_J721E_WIZ=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y -- 2.17.1
[PATCH 15/16] env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM
MAIN CPSW0 requires the PHY to be powered on and reset for QSGMII operation. Add a env variable to configure driving "0" on ENET_EXP_PWRDN controlled by GPIO EXPANDER2 (I2C Addr: 0x22), PIN: 17 and driving "1" on ENET_EXP_RESETZ controlled by GPIO EXPANDER2 (I2C Addr: 0x22), PIN: 18. Signed-off-by: Kishon Vijay Abraham I --- include/configs/j721e_evm.h | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h index b707fc4e89..00d0a18a68 100644 --- a/include/configs/j721e_evm.h +++ b/include/configs/j721e_evm.h @@ -139,11 +139,24 @@ #endif /* CONFIG_TARGET_J721E_A72_EVM */ #ifdef CONFIG_TARGET_J7200_A72_EVM +#define EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY \ + "do_main_cpsw0_qsgmii_phyinit=1\0" \ + "init_main_cpsw0_qsgmii_phy=gpio set gpio@22_17;" \ +"gpio clear gpio@22_16\0" \ + "main_cpsw0_qsgmii_phyinit="\ + "if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1 && test ${dorprocboot} -eq 1 && " \ + "test ${boot} = mmc; then " \ + "run init_main_cpsw0_qsgmii_phy;" \ + "fi;\0" #define DEFAULT_RPROCS "" \ "2 /lib/firmware/j7200-main-r5f0_0-fw " \ "3 /lib/firmware/j7200-main-r5f0_1-fw " #endif /* CONFIG_TARGET_J7200_A72_EVM */ +#ifndef EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY +#define EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY +#endif + /* set default dfu_bufsiz to 128KB (sector size of OSPI) */ #define EXTRA_ENV_DFUARGS \ "dfu_bufsiz=0x2\0" \ @@ -170,7 +183,8 @@ EXTRA_ENV_RPROC_SETTINGS\ EXTRA_ENV_DFUARGS \ DEFAULT_UFS_TI_ARGS \ - EXTRA_ENV_J721E_BOARD_SETTINGS_MTD + EXTRA_ENV_J721E_BOARD_SETTINGS_MTD \ + EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY /* Now for the remaining common defines */ #include -- 2.17.1
[PATCH 16/16] configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY
Update the default BOOTCOMMAND to provide an automatic and easier way to configure ethernet PHY before loading the firmware. Signed-off-by: Kishon Vijay Abraham I --- configs/j7200_evm_a72_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig index bf78b36d22..5929bba82a 100644 --- a/configs/j7200_evm_a72_defconfig +++ b/configs/j7200_evm_a72_defconfig @@ -30,7 +30,7 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 # CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_OF_BOARD_SETUP=y -CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern" +CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern" CONFIG_LOGLEVEL=7 CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y -- 2.17.1
Re: [PATCH 1/6] ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > From: Etienne Carriere > > Define in the RCC clock provider node which root clocks the driver > depends on. These are root oscillators, which may be present or > not, upon FDT content. > > This update binding is introduced in Linux kernel device tree by patch > "ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15" > > This patch is a preliminary step for SCMI support of stm32mp15 > boards with trusted boot chain, based on TF-A or OP-TEE. > > Signed-off-by: Etienne Carriere > Signed-off-by: Patrick Delaunay > --- > > Reference: > > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210126090120.19900-13-gabriel.fernan...@foss.st.com/ > > > arch/arm/dts/stm32mp151.dtsi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi > index eedea6f4b8..b564fc6269 100644 > --- a/arch/arm/dts/stm32mp151.dtsi > +++ b/arch/arm/dts/stm32mp151.dtsi > @@ -1136,6 +1136,10 @@ > reg = <0x5000 0x1000>; > #clock-cells = <1>; > #reset-cells = <1>; > + > + clock-names = "hse", "hsi", "csi", "lse", "lsi"; > + clocks = <&clk_hse>, <&clk_hsi>, <&clk_csi>, > + <&clk_lse>, <&clk_lsi>; > }; > > pwr_regulators: pwr@50001000 { > Reviewed-by: Patrice Chotard
Re: [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > Currently we use incremental linking (ld -r) to link several object > files from one directory into one built-in.o object file containing the > linked code from that directory (and its subdirectories). > > Linux has, some time ago, moved to thin archives instead. > > Thin archives are archives (.a) that do not really contain the object > files, only references to them. > > Using thin archives instead of incremental linking > - saves disk space > - apparently works better with dead code elimination > - makes things easier for LTO > > The third point is the important one for us. With incremental linking > there are several options how to do LTO, and that would unnecessarily > complicate things. > > On the other hand, by using thin archives we can make (via the > --whole-archive use flag) the final linking behave as if we passed all > the object files from the archives to the linking program as arguments. > > We also need to use the P flag for ar, otherwise final linking may fail. > > Signed-off-by: Marek Behún > --- > Makefile | 4 ++-- > arch/sandbox/config.mk | 10 +++--- > scripts/Makefile.build | 16 > scripts/Makefile.spl | 4 ++-- > 4 files changed, 19 insertions(+), 15 deletions(-) > > diff --git a/Makefile b/Makefile > index 7b0ba9df9a..6dc47810ea 100644 > --- a/Makefile > +++ b/Makefile > @@ -1754,9 +1754,9 @@ ARCH_POSTLINK := $(wildcard > $(srctree)/arch/$(ARCH)/Makefile.postlink) > quiet_cmd_u-boot__ ?= LD $@ >cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ > \ > -T u-boot.lds $(u-boot-init) > \ > - --start-group > \ > + --start-group --whole-archive > \ --start-group is useless now. > $(u-boot-main) > \ > - --end-group > \ > + --no-whole-archive --end-group > \ and --end-group > $(PLATFORM_LIBS) -Map u-boot.map; > \ > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > > diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk > index 189e9c2b0c..d11b9c63c9 100644 > --- a/arch/sandbox/config.mk > +++ b/arch/sandbox/config.mk > @@ -17,13 +17,17 @@ PLATFORM_CPPFLAGS += $(shell $(SDL_CONFIG) --cflags) > endif > > cmd_u-boot__ = $(CC) -o $@ -Wl,-T u-boot.lds $(u-boot-init) \ > - -Wl,--start-group $(u-boot-main) -Wl,--end-group \ > + -Wl,--start-group -Wl,--whole-archive \ > + $(u-boot-main) \ > + -Wl,--no-whole-archive -Wl,--end-group \ > $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map > > cmd_u-boot-spl = (cd $(obj) && $(CC) -o $(SPL_BIN) -Wl,-T u-boot-spl.lds \ > $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \ > - -Wl,--start-group $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \ > - $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) -Wl,--end-group \ > + -Wl,--start-group -Wl,--whole-archive \ > + $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \ > + $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \ > + -Wl,--no-whole-archive -Wl,--end-group \ > $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot-spl.map -Wl,--gc-sections) > > CONFIG_ARCH_DEVICE_TREE := sandbox > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index 705a886cb9..a9a02d7d33 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -331,12 +331,11 @@ $(sort $(subdir-obj-y)): $(subdir-ym) ; > # Rule to compile a set of .o files into one .o file > # > ifdef builtin-target > -quiet_cmd_link_o_target = LD $@ > +quiet_cmd_link_o_target = AR $@ > # If the list of objects to link is empty, just create an empty built-in.o > cmd_link_o_target = $(if $(strip $(obj-y)),\ > - $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \ > - $(cmd_secanalysis),\ > - rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@) > + rm -f $@; $(AR) cDPrsT $@ $(filter $(obj-y), $^), \ > + rm -f $@; $(AR) cPrsT$(KBUILD_ARFLAGS) $@) nits: should we use D for the empty one for consistency? > > $(builtin-target): $(obj-y) FORCE > $(call if_changed,link_o_target) > @@ -362,7 +361,7 @@ $(modorder-target): $(subdir-ym) FORCE > # > ifdef lib-target > quiet_cmd_link_l_target = AR $@ > -cmd_link_l_target = rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@ $(lib-y) > +cmd_link_l_target = rm -f $@; $(AR) cPrs$(KBUILD_ARFLAGS) $@ $(lib-y) It looks this line change is not needed > > $(lib-target): $(lib-y) FORCE > $(call if_changed,link_l_target) > @@ -382,10 +381,11 @@ $(filter $(addprefix $(obj)/,
Re: [PATCH 2/6] clk: stm32mp1: gets root clocks from fdt
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > From: Etienne Carriere > > This change makes stm32mp1 clock driver to get the root clocks > reference from the device node in the FDT rather than fetching > straight these clocks by their name. Driver now stores the > clock reference and use it to know if a root clock is present, > get its rate or gets its related udevice reference. > > Signed-off-by: Etienne Carriere > Signed-off-by: Patrick Delaunay > --- > > drivers/clk/clk_stm32mp1.c | 62 ++ > 1 file changed, 23 insertions(+), 39 deletions(-) > > diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c > index 848e33f4e8..0c0ef366a1 100644 > --- a/drivers/clk/clk_stm32mp1.c > +++ b/drivers/clk/clk_stm32mp1.c > @@ -250,7 +250,7 @@ DECLARE_GLOBAL_DATA_PTR; > enum stm32mp1_parent_id { > /* > * _HSI, _HSE, _CSI, _LSI, _LSE should not be moved > - * they are used as index in osc[] as entry point > + * they are used as index in osc_clk[] as clock reference > */ > _HSI, > _HSE, > @@ -430,8 +430,7 @@ struct stm32mp1_clk_data { > struct stm32mp1_clk_priv { > fdt_addr_t base; > const struct stm32mp1_clk_data *data; > - ulong osc[NB_OSC]; > - struct udevice *osc_dev[NB_OSC]; > + struct clk osc_clk[NB_OSC]; > }; > > #define STM32MP1_CLK(off, b, idx, s) \ > @@ -790,7 +789,7 @@ static ulong stm32mp1_clk_get_fixed(struct > stm32mp1_clk_priv *priv, int idx) > return 0; > } > > - return priv->osc[idx]; > + return clk_get_rate(&priv->osc_clk[idx]); > } > > static int stm32mp1_clk_get_id(struct stm32mp1_clk_priv *priv, unsigned long > id) > @@ -1545,7 +1544,7 @@ static int stm32mp1_hsidiv(fdt_addr_t rcc, ulong > hsifreq) > break; > > if (hsidiv == 4) { > - log_err("clk-hsi frequency invalid"); > + log_err("hsi frequency invalid"); > return -1; > } > > @@ -1952,13 +1951,13 @@ static int stm32mp1_clktree(struct udevice *dev) >* switch ON oscillator found in device-tree, >* HSI already ON after bootrom >*/ > - if (priv->osc[_LSI]) > + if (clk_valid(&priv->osc_clk[_LSI])) > stm32mp1_lsi_set(rcc, 1); > > - if (priv->osc[_LSE]) { > + if (clk_valid(&priv->osc_clk[_LSE])) { > int bypass, digbyp; > u32 lsedrv; > - struct udevice *dev = priv->osc_dev[_LSE]; > + struct udevice *dev = priv->osc_clk[_LSE].dev; > > bypass = dev_read_bool(dev, "st,bypass"); > digbyp = dev_read_bool(dev, "st,digbypass"); > @@ -1969,9 +1968,9 @@ static int stm32mp1_clktree(struct udevice *dev) > stm32mp1_lse_enable(rcc, bypass, digbyp, lsedrv); > } > > - if (priv->osc[_HSE]) { > + if (clk_valid(&priv->osc_clk[_HSE])) { > int bypass, digbyp, css; > - struct udevice *dev = priv->osc_dev[_HSE]; > + struct udevice *dev = priv->osc_clk[_HSE].dev; > > bypass = dev_read_bool(dev, "st,bypass"); > digbyp = dev_read_bool(dev, "st,digbypass"); > @@ -1996,8 +1995,8 @@ static int stm32mp1_clktree(struct udevice *dev) > > /* configure HSIDIV */ > dev_dbg(dev, "configure HSIDIV\n"); > - if (priv->osc[_HSI]) { > - stm32mp1_hsidiv(rcc, priv->osc[_HSI]); > + if (clk_valid(&priv->osc_clk[_HSI])) { > + stm32mp1_hsidiv(rcc, clk_get_rate(&priv->osc_clk[_HSI])); > stgen_config(priv); > } > > @@ -2043,7 +2042,7 @@ static int stm32mp1_clktree(struct udevice *dev) > } > > /* wait LSE ready before to use it */ > - if (priv->osc[_LSE]) > + if (clk_valid(&priv->osc_clk[_LSE])) > stm32mp1_lse_wait(rcc); > > /* configure with expected clock source */ > @@ -2082,7 +2081,7 @@ static int stm32mp1_clktree(struct udevice *dev) > > dev_dbg(dev, "oscillator off\n"); > /* switch OFF HSI if not found in device-tree */ > - if (!priv->osc[_HSI]) > + if (!clk_valid(&priv->osc_clk[_HSI])) > stm32mp1_hsi_set(rcc, 0); > > /* Software Self-Refresh mode (SSR) during DDR initilialization */ > @@ -2178,40 +2177,25 @@ static ulong stm32mp1_clk_set_rate(struct clk *clk, > unsigned long clk_rate) > return -EINVAL; > } > > -static void stm32mp1_osc_clk_init(const char *name, > - struct stm32mp1_clk_priv *priv, > - int index) > -{ > - struct clk clk; > - struct udevice *dev = NULL; > - > - priv->osc[index] = 0; > - clk.id = 0; > - if (!uclass_get_device_by_name(UCLASS_CLK, name, &dev)) { > - if (clk_request(dev, &clk)) > - log_err("%s request", name); > - else > - priv->osc[index] = clk_get_rate(&clk); > - } > - priv->osc_dev[index] = d
Re: [Uboot-stm32] [PATCH 3/6] scmi: Include device_compat.h
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > Include the file needed for log function prototype, this patch solves the > compilation issue for undefined reference to `dev_err'. > > Signed-off-by: Patrick Delaunay > --- > > drivers/firmware/scmi/smccc_agent.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/firmware/scmi/smccc_agent.c > b/drivers/firmware/scmi/smccc_agent.c > index 64d0929f69..81c2884bb7 100644 > --- a/drivers/firmware/scmi/smccc_agent.c > +++ b/drivers/firmware/scmi/smccc_agent.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [Uboot-stm32] [PATCH 4/6] scmi: define LOG_CATEGORY
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > Define LOG_CATEGORY to allow filtering with log command. > > Signed-off-by: Patrick Delaunay > --- > > drivers/firmware/scmi/mailbox_agent.c| 2 ++ > drivers/firmware/scmi/sandbox-scmi_agent.c | 2 ++ > drivers/firmware/scmi/sandbox-scmi_devices.c | 2 ++ > drivers/firmware/scmi/scmi_agent-uclass.c| 2 ++ > drivers/firmware/scmi/smccc_agent.c | 2 ++ > drivers/firmware/scmi/smt.c | 2 ++ > 6 files changed, 12 insertions(+) > > diff --git a/drivers/firmware/scmi/mailbox_agent.c > b/drivers/firmware/scmi/mailbox_agent.c > index 3f4b04a4ae..8043e2c2de 100644 > --- a/drivers/firmware/scmi/mailbox_agent.c > +++ b/drivers/firmware/scmi/mailbox_agent.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2020 Linaro Limited. > */ > > +#define LOG_CATEGORY UCLASS_SCMI_AGENT > + > #include > #include > #include > diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c > b/drivers/firmware/scmi/sandbox-scmi_agent.c > index 35de68c75d..97a5dace15 100644 > --- a/drivers/firmware/scmi/sandbox-scmi_agent.c > +++ b/drivers/firmware/scmi/sandbox-scmi_agent.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2020, Linaro Limited > */ > > +#define LOG_CATEGORY UCLASS_SCMI_AGENT > + > #include > #include > #include > diff --git a/drivers/firmware/scmi/sandbox-scmi_devices.c > b/drivers/firmware/scmi/sandbox-scmi_devices.c > index 1a6fafbf53..69239a198f 100644 > --- a/drivers/firmware/scmi/sandbox-scmi_devices.c > +++ b/drivers/firmware/scmi/sandbox-scmi_devices.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2020, Linaro Limited > */ > > +#define LOG_CATEGORY UCLASS_MISC > + > #include > #include > #include > diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c > b/drivers/firmware/scmi/scmi_agent-uclass.c > index 516e690ac2..2491e0a747 100644 > --- a/drivers/firmware/scmi/scmi_agent-uclass.c > +++ b/drivers/firmware/scmi/scmi_agent-uclass.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2020 Linaro Limited. > */ > > +#define LOG_CATEGORY UCLASS_SCMI_AGENT > + > #include > #include > #include > diff --git a/drivers/firmware/scmi/smccc_agent.c > b/drivers/firmware/scmi/smccc_agent.c > index 81c2884bb7..f185891e8f 100644 > --- a/drivers/firmware/scmi/smccc_agent.c > +++ b/drivers/firmware/scmi/smccc_agent.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2020 Linaro Limited. > */ > > +#define LOG_CATEGORY UCLASS_SCMI_AGENT > + > #include > #include > #include > diff --git a/drivers/firmware/scmi/smt.c b/drivers/firmware/scmi/smt.c > index d25478796a..60b9d499b7 100644 > --- a/drivers/firmware/scmi/smt.c > +++ b/drivers/firmware/scmi/smt.c > @@ -4,6 +4,8 @@ > * Copyright (C) 2019-2020 Linaro Limited. > */ > > +#define LOG_CATEGORY UCLASS_SCMI_AGENT > + > #include > #include > #include > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [Uboot-stm32] [PATCH 3/6] scmi: Include device_compat.h
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > Include the file needed for log function prototype, this patch solves the > compilation issue for undefined reference to `dev_err'. > > Signed-off-by: Patrick Delaunay > --- > > drivers/firmware/scmi/smccc_agent.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/firmware/scmi/smccc_agent.c > b/drivers/firmware/scmi/smccc_agent.c > index 64d0929f69..81c2884bb7 100644 > --- a/drivers/firmware/scmi/smccc_agent.c > +++ b/drivers/firmware/scmi/smccc_agent.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [Uboot-stm32] [PATCH 5/6] scmi: cosmetic: reorder include files
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > Reorder include files in expected order. > > Signed-off-by: Patrick Delaunay > --- > > drivers/firmware/scmi/mailbox_agent.c | 2 +- > drivers/firmware/scmi/scmi_agent-uclass.c | 3 +-- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/firmware/scmi/mailbox_agent.c > b/drivers/firmware/scmi/mailbox_agent.c > index 8043e2c2de..ea35e7e09e 100644 > --- a/drivers/firmware/scmi/mailbox_agent.c > +++ b/drivers/firmware/scmi/mailbox_agent.c > @@ -7,11 +7,11 @@ > > #include > #include > -#include > #include > #include > #include > #include > +#include > #include > #include > > diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c > b/drivers/firmware/scmi/scmi_agent-uclass.c > index 2491e0a747..527163b5ce 100644 > --- a/drivers/firmware/scmi/scmi_agent-uclass.c > +++ b/drivers/firmware/scmi/scmi_agent-uclass.c > @@ -7,11 +7,10 @@ > > #include > #include > -#include > #include > #include > #include > - > +#include > #include > #include > > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 6/6] configs: stm32mp1_trusted_defconfig rely on SCMI support
Hi Patrick On 2/24/21 11:19 AM, Patrick Delaunay wrote: > Enable SCMI clock and reset domain support for stm32mp1 platform > and ARM SMC mailbox driver used as communication channel for > SCMI messages between non-secure world and secure SCMI server. > > Signed-off-by: Patrick Delaunay > --- > > configs/stm32mp15_trusted_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/stm32mp15_trusted_defconfig > b/configs/stm32mp15_trusted_defconfig > index da31b74cde..e1746332e6 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -51,6 +51,7 @@ CONFIG_ENV_UBI_VOLUME="uboot_config" > CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r" > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_STM32_ADC=y > +CONFIG_CLK_SCMI=y > CONFIG_SET_DFU_ALT_INFO=y > CONFIG_USB_FUNCTION_FASTBOOT=y > CONFIG_FASTBOOT_BUF_ADDR=0xC000 > @@ -107,6 +108,7 @@ CONFIG_DM_REGULATOR_GPIO=y > CONFIG_DM_REGULATOR_STM32_VREFBUF=y > CONFIG_DM_REGULATOR_STPMIC1=y > CONFIG_REMOTEPROC_STM32_COPRO=y > +CONFIG_RESET_SCMI=y > CONFIG_DM_RNG=y > CONFIG_RNG_STM32MP1=y > CONFIG_DM_RTC=y > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH] board: st: remove the nand MTD configuration for NOR boot in stm32mp1 board
Hi Patrick On 2/25/21 11:49 AM, Patrick Delaunay wrote: > Since commit d5d726d3cc47 ("configs: stm32mp1: only support SD card after > NOR in bootcmd_stm32mp"), the stm32mp1 boards only support SD card after > NOR boot device, so the MTD partitions for nand0 or spi-nand0 are useless > (no need of "UBI" partition in nand0 or spi-nand0). > > This patch removes these nand MTD update for nor boot and simplify nand0 > and spi-nand0 support (remove the mtd_boot variable). > > Signed-off-by: Patrick Delaunay > Signed-off-by: Patrick Delaunay > --- > > board/st/common/stm32mp_mtdparts.c | 16 +--- > 1 file changed, 5 insertions(+), 11 deletions(-) > > diff --git a/board/st/common/stm32mp_mtdparts.c > b/board/st/common/stm32mp_mtdparts.c > index 69eb10844d..f074fc189d 100644 > --- a/board/st/common/stm32mp_mtdparts.c > +++ b/board/st/common/stm32mp_mtdparts.c > @@ -122,28 +122,24 @@ void board_mtdparts_default(const char **mtdids, const > char **mtdparts) > log_debug("mtd device = %s\n", dev->name); > } > > - if (nor || nand) { > + if (nand) { > mtd = get_mtd_device_nm("nand0"); > if (!IS_ERR_OR_NULL(mtd)) { > - const char *mtd_boot = CONFIG_MTDPARTS_NAND0_BOOT; > const char *mtd_tee = CONFIG_MTDPARTS_NAND0_TEE; > - > board_set_mtdparts("nand0", ids, parts, > -!nor ? mtd_boot : NULL, > +CONFIG_MTDPARTS_NAND0_BOOT, > !nor && tee ? mtd_tee : NULL, > "-(UBI)"); > put_mtd_device(mtd); > } > } > > - if (nor || spinand) { > + if (spinand) { > mtd = get_mtd_device_nm("spi-nand0"); > if (!IS_ERR_OR_NULL(mtd)) { > - const char *mtd_boot = CONFIG_MTDPARTS_SPINAND0_BOOT; > const char *mtd_tee = CONFIG_MTDPARTS_SPINAND0_TEE; > - > board_set_mtdparts("spi-nand0", ids, parts, > -!nor ? mtd_boot : NULL, > +CONFIG_MTDPARTS_SPINAND0_BOOT, > !nor && tee ? mtd_tee : NULL, > "-(UBI)"); > put_mtd_device(mtd); > @@ -152,11 +148,9 @@ void board_mtdparts_default(const char **mtdids, const > char **mtdparts) > > if (nor) { > if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev)) { > - const char *mtd_boot = CONFIG_MTDPARTS_NOR0_BOOT; > const char *mtd_tee = CONFIG_MTDPARTS_NOR0_TEE; > - > board_set_mtdparts("nor0", ids, parts, > -mtd_boot, > +CONFIG_MTDPARTS_NOR0_BOOT, > tee ? mtd_tee : NULL, > "-(nor_user)"); > } > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 1/4] stm32mp: stm32prog: Add Kconfig file for stm32prog command
Hi Patrick On 2/25/21 1:37 PM, Patrick Delaunay wrote: > Move CONFIG_CMD_STM32PROG in a specific Kconfig file for stm32prog command. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/Kconfig | 18 +- > arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 18 ++ > 2 files changed, 19 insertions(+), 17 deletions(-) > create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > > diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig > index f538d7cb83..079d66a80c 100644 > --- a/arch/arm/mach-stm32mp/Kconfig > +++ b/arch/arm/mach-stm32mp/Kconfig > @@ -121,23 +121,6 @@ config STM32_ETZPC > help > Say y to enable STM32 Extended TrustZone Protection > > -config CMD_STM32PROG > - bool "command stm32prog for STM32CudeProgrammer" > - select DFU > - select DFU_RAM > - select DFU_VIRT > - select PARTITION_TYPE_GUID > - imply CMD_GPT if MMC > - imply CMD_MTD if MTD > - imply DFU_MMC if MMC > - imply DFU_MTD if MTD > - help > - activate a specific command stm32prog for STM32MP soc family > - witch update the device with the tools STM32CubeProgrammer, > - using UART with STM32 protocol or USB with DFU protocol > - NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based > - on U-Boot DFU framework > - > config CMD_STM32KEY > bool "command stm32key to fuse public key hash" > default y > @@ -177,6 +160,7 @@ config DEBUG_UART_CLOCK > default 6400 > endif > > +source "arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig" > source "board/st/stm32mp1/Kconfig" > source "board/dhelectronics/dh_stm32mp1/Kconfig" > > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > new file mode 100644 > index 00..609a678793 > --- /dev/null > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > @@ -0,0 +1,18 @@ > + > +config CMD_STM32PROG > + bool "command stm32prog for STM32CudeProgrammer" > + select DFU > + select DFU_RAM > + select DFU_VIRT > + select PARTITION_TYPE_GUID > + imply CMD_GPT if MMC > + imply CMD_MTD if MTD > + imply DFU_MMC if MMC > + imply DFU_MTD if MTD > + help > + activate a specific command stm32prog for STM32MP soc family > + witch update the device with the tools STM32CubeProgrammer, > + using UART with STM32 protocol or USB with DFU protocol > + NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based > + on U-Boot DFU framework > + > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 2/4] stm32mp: stm32prog: Add CONFIG_CMD_STM32PROG_SERIAL and _USB
Hi Patrick On 2/25/21 1:37 PM, Patrick Delaunay wrote: > Add CONFIG_CMD_STM32PROG_SERIAL and CONFIG_CMD_STM32PROG_USB to > independently select the support of UART or USB communication for > STM32CubeProgrammer. > > For serial boot over UART, user can deactivate CONFIG_CMD_STM32PROG_SERIAL > to use U-Boot console of binary loaded by UART (for board bring-up for > example). > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/Makefile| 2 +- > arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 20 ++-- > arch/arm/mach-stm32mp/cmd_stm32prog/Makefile | 8 +++ > .../cmd_stm32prog/cmd_stm32prog.c | 4 ++-- > .../mach-stm32mp/cmd_stm32prog/stm32prog.h| 23 ++- > arch/arm/mach-stm32mp/cpu.c | 5 ++-- > board/st/common/stm32mp_dfu.c | 9 > 7 files changed, 55 insertions(+), 16 deletions(-) > > diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile > index c8aa24d489..aa39867080 100644 > --- a/arch/arm/mach-stm32mp/Makefile > +++ b/arch/arm/mach-stm32mp/Makefile > @@ -11,7 +11,7 @@ obj-y += bsec.o > ifdef CONFIG_SPL_BUILD > obj-y += spl.o > else > -obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog/ > +obj-y += cmd_stm32prog/ > obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o > obj-$(CONFIG_ARMV7_PSCI) += psci.o > obj-$(CONFIG_TFABOOT) += boot_params.o > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > index 609a678793..f4c0d18d4d 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig > @@ -11,8 +11,24 @@ config CMD_STM32PROG > imply DFU_MTD if MTD > help > activate a specific command stm32prog for STM32MP soc family > - witch update the device with the tools STM32CubeProgrammer, > - using UART with STM32 protocol or USB with DFU protocol > + witch update the device with the tools STM32CubeProgrammer > NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based > on U-Boot DFU framework > > +config CMD_STM32PROG_USB > + bool "support stm32prog over USB" > + depends on CMD_STM32PROG > + default y > + help > + activate the command "stm32prog usb" for STM32MP soc family > + witch update the device with the tools STM32CubeProgrammer, > + using USB with DFU protocol > + > +config CMD_STM32PROG_SERIAL > + bool "support stm32prog over UART" > + depends on CMD_STM32PROG > + default y > + help > + activate the command "stm32prog serial" for STM32MP soc family > + with the tools STM32CubeProgrammer using U-Boot serial device > + and UART protocol. > \ No newline at end of file > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile > b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile > index 548a378921..b57e1bf870 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile > @@ -3,7 +3,7 @@ > # Copyright (C) 2020, STMicroelectronics - All Rights Reserved > # > > -obj-y += cmd_stm32prog.o > -obj-y += stm32prog.o > -obj-y += stm32prog_serial.o > -obj-y += stm32prog_usb.o > +obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog.o > +obj-$(CONFIG_CMD_STM32PROG) += stm32prog.o > +obj-$(CONFIG_CMD_STM32PROG_SERIAL) += stm32prog_serial.o > +obj-$(CONFIG_CMD_STM32PROG_USB) += stm32prog_usb.o > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > index 34a6be66c3..a7e2861764 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > @@ -50,9 +50,9 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, > int argc, > if (argc < 3 || argc > 5) > return CMD_RET_USAGE; > > - if (!strcmp(argv[1], "usb")) > + if (IS_ENABLED(CONFIG_CMD_STM32PROG_USB) && !strcmp(argv[1], "usb")) > link = LINK_USB; > - else if (!strcmp(argv[1], "serial")) > + else if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL) && !strcmp(argv[1], > "serial")) > link = LINK_SERIAL; > > if (link == LINK_UNDEFINED) { > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h > b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h > index be482c3402..18af99c78b 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h > @@ -177,9 +177,30 @@ char *stm32prog_get_error(struct stm32prog_data *data); > > /* Main function */ > int stm32prog_init(struct stm32prog_data *data, ulong addr, ulong size); > +void stm32prog_clean(struct stm32prog_data *data); > + > +#ifdef CONFIG_CMD_STM32PROG_SERIAL > int stm32prog_serial_init(struct stm32prog_data *data, int link_dev); > bool stm32prog_serial_loop(struct
Re: [PATCH 3/4] stm32mp: stm32prog: reactivate console and display serial error
Hi Patrick On 2/25/21 1:37 PM, Patrick Delaunay wrote: > When serial instance is not found in device tree, the console > should be enabled and the error should be indicated. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/cpu.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c > index a453f89d02..527b6290de 100644 > --- a/arch/arm/mach-stm32mp/cpu.c > +++ b/arch/arm/mach-stm32mp/cpu.c > @@ -476,11 +476,17 @@ static void setup_boot_mode(void) > break; > /* serial : search associated alias in devicetree */ > sprintf(cmd, "serial@%x", serial_addr[instance]); > - if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev)) > - break; > - if (fdtdec_get_alias_seq(gd->fdt_blob, "serial", > - dev_of_offset(dev), &alias)) > + if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev) || > + fdtdec_get_alias_seq(gd->fdt_blob, "serial", > + dev_of_offset(dev), &alias)) { > + /* restore console on error */ > + if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL)) > + gd->flags &= ~(GD_FLG_SILENT | > +GD_FLG_DISABLE_CONSOLE); > + printf("serial%d = %s not found in device tree!\n", > +instance, cmd); > break; > + } > sprintf(cmd, "%d", alias); > env_set("boot_device", "serial"); > env_set("boot_instance", cmd); > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 4/4] stm32mp: stm32prog: replace alias by serial device sequence number
Hi Patrick On 2/25/21 1:37 PM, Patrick Delaunay wrote: > The command "stm32prog serial " can directly use the device sequence > number of serial uclass as this sequence number is egual to alias when it > exist; this assumption simplify the code and avoid access to gd->fdt_blob > and the device tree parsing. > > Signed-off-by: Patrick Delaunay > --- > > .../cmd_stm32prog/stm32prog_serial.c | 29 --- > arch/arm/mach-stm32mp/cpu.c | 11 +++ > 2 files changed, 10 insertions(+), 30 deletions(-) > > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c > b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c > index 373ca20886..a51e5e3ec8 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c > @@ -187,36 +187,19 @@ static int stm32prog_read(struct stm32prog_data *data, > u8 phase, u32 offset, > int stm32prog_serial_init(struct stm32prog_data *data, int link_dev) > { > struct udevice *dev = NULL; > - int node; > - char alias[10]; > - const char *path; > struct dm_serial_ops *ops; > /* no parity, 8 bits, 1 stop */ > u32 serial_config = SERIAL_DEFAULT_CONFIG; > > down_serial_dev = NULL; > > - sprintf(alias, "serial%d", link_dev); > - path = fdt_get_alias(gd->fdt_blob, alias); > - if (!path) { > - log_err("%s alias not found", alias); > - return -ENODEV; > - } > - node = fdt_path_offset(gd->fdt_blob, path); > - if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node, > - &dev)) { > - down_serial_dev = dev; > - } else if (node > 0 && > -!lists_bind_fdt(gd->dm_root, offset_to_ofnode(node), > -&dev, false)) { > - if (!device_probe(dev)) > - down_serial_dev = dev; > - } > - if (!down_serial_dev) { > - log_err("%s = %s device not found", alias, path); > + if (uclass_get_device_by_seq(UCLASS_SERIAL, link_dev, &dev)) { > + log_err("serial %d device not found\n", link_dev); > return -ENODEV; > } > > + down_serial_dev = dev; > + > /* force silent console on uart only when used */ > if (gd->cur_serial_dev == down_serial_dev) > gd->flags |= GD_FLG_DISABLE_CONSOLE | GD_FLG_SILENT; > @@ -226,11 +209,11 @@ int stm32prog_serial_init(struct stm32prog_data *data, > int link_dev) > ops = serial_get_ops(down_serial_dev); > > if (!ops) { > - log_err("%s = %s missing ops", alias, path); > + log_err("serial %d = %s missing ops\n", link_dev, dev->name); > return -ENODEV; > } > if (!ops->setconfig) { > - log_err("%s = %s missing setconfig", alias, path); > + log_err("serial %d = %s missing setconfig\n", link_dev, > dev->name); > return -ENODEV; > } > > diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c > index 527b6290de..9a76b5633b 100644 > --- a/arch/arm/mach-stm32mp/cpu.c > +++ b/arch/arm/mach-stm32mp/cpu.c > @@ -466,7 +466,6 @@ static void setup_boot_mode(void) > unsigned int instance = (boot_mode & TAMP_BOOT_INSTANCE_MASK) - 1; > u32 forced_mode = (boot_ctx & TAMP_BOOT_FORCED_MASK); > struct udevice *dev; > - int alias; > > log_debug("%s: boot_ctx=0x%x => boot_mode=%x, instance=%d forced=%x\n", > __func__, boot_ctx, boot_mode, instance, forced_mode); > @@ -474,20 +473,18 @@ static void setup_boot_mode(void) > case BOOT_SERIAL_UART: > if (instance > ARRAY_SIZE(serial_addr)) > break; > - /* serial : search associated alias in devicetree */ > + /* serial : search associated node in devicetree */ > sprintf(cmd, "serial@%x", serial_addr[instance]); > - if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev) || > - fdtdec_get_alias_seq(gd->fdt_blob, "serial", > - dev_of_offset(dev), &alias)) { > + if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev)) { > /* restore console on error */ > if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL)) > gd->flags &= ~(GD_FLG_SILENT | > GD_FLG_DISABLE_CONSOLE); > - printf("serial%d = %s not found in device tree!\n", > + printf("uart%d = %s not found in device tree!\n", > instance, cmd); > break; > } > - sprintf(cmd, "%d", alias); > + sprintf(cmd, "%d", dev_seq(dev)); > env_set("boot_device", "serial"); > env_set("boot_instance", cmd); > > Review
[PATCH v2 1/4] watchdog: Set/unset GD_FLG_WDT_READY flag in wdt_start()/wdt_stop()
Watchdog is ready after successful call of ops->start() callback in wdt_start() function. And is stopped after successful call of ops->stop() callback in wdt_stop function. So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop() function. This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is running. And ensures that flag is also also when watchdog was started not only by initr_watchdog() call (e.g. by U-Boot 'wdt' command). Signed-off-by: Pali Rohár --- drivers/watchdog/wdt-uclass.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 28f7918c4673..3f707f61f74f 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -51,7 +51,6 @@ int initr_watchdog(void) } wdt_start(gd->watchdog_dev, timeout * 1000, 0); - gd->flags |= GD_FLG_WDT_READY; printf("WDT: Started with%s servicing (%ds timeout)\n", IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); @@ -61,21 +60,31 @@ int initr_watchdog(void) int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) { const struct wdt_ops *ops = device_get_ops(dev); + int ret; if (!ops->start) return -ENOSYS; - return ops->start(dev, timeout_ms, flags); + ret = ops->start(dev, timeout_ms, flags); + if (ret == 0) + gd->flags |= GD_FLG_WDT_READY; + + return ret; } int wdt_stop(struct udevice *dev) { const struct wdt_ops *ops = device_get_ops(dev); + int ret; if (!ops->stop) return -ENOSYS; - return ops->stop(dev); + ret = ops->stop(dev); + if (ret == 0) + gd->flags &= ~GD_FLG_WDT_READY; + + return ret; } int wdt_reset(struct udevice *dev) -- 2.20.1
Re: [PATCH] stm32mp: bsec: manage clock when present in device tree
Hi Patrick On 2/25/21 1:43 PM, Patrick Delaunay wrote: > Enable the clocks during bsec probe when they are present in device tree. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/bsec.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c > index 88c7aec8b4..fe39bd80cf 100644 > --- a/arch/arm/mach-stm32mp/bsec.c > +++ b/arch/arm/mach-stm32mp/bsec.c > @@ -6,6 +6,7 @@ > #define LOG_CATEGORY UCLASS_MISC > > #include > +#include > #include > #include > #include > @@ -490,6 +491,15 @@ static int stm32mp_bsec_probe(struct udevice *dev) > { > int otp; > struct stm32mp_bsec_plat *plat; > + struct clk_bulk clk_bulk; > + int ret; > + > + ret = clk_get_bulk(dev, &clk_bulk); > + if (!ret) { > + ret = clk_enable_bulk(&clk_bulk); > + if (ret) > + return ret; > + } > > /* >* update unlocked shadow for OTP cleared by the rom code > Reviewed-by: Patrice Chotard Thanks Patrice
[PATCH v2 4/4] arm: mvebu: Espressobin: Enable watchdog support but do not start it
Espressobin had disabled watchdog support (CONFIG_WDT) because older stable Linux kernel versions (which are used by current stable OpenWRT and Debian versions) do not have support for Armada 3700 watchdog driver. Therefore they are not able to periodically kick watchdog so Espressobin enter into boot loop. This change enable CONFIG_WDT, CONFIG_WDT_ARMADA_37XX and CONFIG_CMD_WDT options which add support for U-Boot 'wdt' command. And unset new CONFIG_WATCHDOG_AUTOSTART option which cause that watchdog is not automatically started by U-Boot during init phase, like when CONFIG_WDT option is not set at all. So with this change, U-Boot on Espressobin would have working 'wdt' command which can be used from boot scripts (e.g. for enabling watchdog prior new Linux booting kernel). But default behavior of watchdog status stays unchanged, U-Boot does not start watchdog on Espressobin during its init phase. Signed-off-by: Pali Rohár --- configs/mvebu_espressobin-88f3720_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index c791f98dfea5..20aa21b06b3d 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -32,6 +32,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y @@ -88,5 +89,8 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ARMADA_37XX=y CONFIG_SHA1=y CONFIG_SHA256=y -- 2.20.1
[PATCH v2 2/4] watchdog: Show error message when initr_watchdog() cannot start watchdog
Function wdt_start() may fail. So in initr_watchdog() function check return value of wdt_start() call and print error message when watchdog starting failed. Signed-off-by: Pali Rohár --- drivers/watchdog/wdt-uclass.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 3f707f61f74f..7500b3ed90e3 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -27,6 +27,7 @@ static ulong reset_period = 1000; int initr_watchdog(void) { u32 timeout = WATCHDOG_TIMEOUT_SECS; + int ret; /* * Init watchdog: This will call the probe function of the @@ -50,7 +51,12 @@ int initr_watchdog(void) 4 * reset_period) / 4; } - wdt_start(gd->watchdog_dev, timeout * 1000, 0); + ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); + if (ret != 0) { + printf("WDT: Failed to start\n"); + return 0; + } + printf("WDT: Started with%s servicing (%ds timeout)\n", IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); -- 2.20.1
[PATCH v2 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog
In some cases it is useful to compile support for U-Boot command 'wdt' without starting HW watchdog in early U-Boot phase. For example when the user want to start the watchdog only on demand by some boot script. This change adds a new compile option WATCHDOG_AUTOSTART to control whether U-Boot should automatically start the watchdog during init phase or not. This option is enabled by default as it was the default behavior prior introducing this new change. When compiling U-Boot users can decide to turn this option off. Signed-off-by: Pali Rohár --- drivers/watchdog/Kconfig | 13 + drivers/watchdog/wdt-uclass.c | 5 + 2 files changed, 18 insertions(+) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 602ccbe41c00..aa76a8f2d239 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -9,6 +9,19 @@ config WATCHDOG this option if you want to service enabled watchdog by U-Boot. Disable this option if you want U-Boot to start watchdog but never service it. +config WATCHDOG_AUTOSTART + bool "Automatically start watchdog timer" + depends on WDT + default y + help + Automatically start watchdog timer and start servicing it during + init phase. Enabled by default. Disable this option if you want + to compile U-Boot with CONFIG_WDT support but do not want to + activate watchdog, like when CONFIG_WDT option is disabled. You + would be able to start watchdog manually by 'wdt' command. Useful + when you want to have support for 'wdt' command but do not want + to have watchdog enabled by default. + config WATCHDOG_TIMEOUT_MSECS int "Watchdog timeout in msec" default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6 diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 7500b3ed90e3..0603ffbd36d9 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -51,6 +51,11 @@ int initr_watchdog(void) 4 * reset_period) / 4; } + if (!CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) { + printf("WDT: Not starting\n"); + return 0; + } + ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); if (ret != 0) { printf("WDT: Failed to start\n"); -- 2.20.1
Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog
On Tuesday 09 March 2021 12:33:24 Stefan Roese wrote: > On 05.03.21 22:36, Pali Rohár wrote: > > In some cases it is useful to compile support for U-Boot command 'wdt' > > without starting HW watchdog in early U-Boot phase. For example when user > > Nitpicking: > when "the" user > > > want to start watchdog only on demand by some boot script. > > > > This change adds a new compile option WATCHDOG_AUTOSTART to control whether > > U-Boot should automatically start watchdog during init phase or not. > > start "the" watchdog > > > > > This option is enabled by default as it was was default behavior prior > > as it was the default > > > introducing this new change. When compiling U-Boot users can decide to turn > > this option off. > > > > Signed-off-by: Pali Rohár > > --- > > drivers/watchdog/Kconfig | 13 + > > drivers/watchdog/wdt-uclass.c | 7 +++ > > 2 files changed, 20 insertions(+) > > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > > index 602ccbe41c00..aa76a8f2d239 100644 > > --- a/drivers/watchdog/Kconfig > > +++ b/drivers/watchdog/Kconfig > > @@ -9,6 +9,19 @@ config WATCHDOG > > this option if you want to service enabled watchdog by U-Boot. Disable > > this option if you want U-Boot to start watchdog but never service it. > > +config WATCHDOG_AUTOSTART > > + bool "Automatically start watchdog timer" > > + depends on WDT > > + default y > > + help > > + Automatically start watchdog timer and start servicing it during > > + init phase. Enabled by default. Disable this option if you want > > + to compile U-Boot with CONFIG_WDT support but do not want to > > + activate watchdog, like when CONFIG_WDT option is disabled. You > > + would be able to start watchdog manually by 'wdt' command. Useful > > + when you want to have support for 'wdt' command but do not want > > + to have watchdog enabled by default. > > + > > config WATCHDOG_TIMEOUT_MSECS > > int "Watchdog timeout in msec" > > default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6 > > diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c > > index 7500b3ed90e3..00a408bf5cc5 100644 > > --- a/drivers/watchdog/wdt-uclass.c > > +++ b/drivers/watchdog/wdt-uclass.c > > @@ -27,7 +27,9 @@ static ulong reset_period = 1000; > > int initr_watchdog(void) > > { > > u32 timeout = WATCHDOG_TIMEOUT_SECS; > > +#ifdef CONFIG_WATCHDOG_AUTOSTART > > int ret; > > +#endif > > Please don't add more #ifdef's if possible, see below... > > > /* > > * Init watchdog: This will call the probe function of the > > @@ -51,6 +53,10 @@ int initr_watchdog(void) > > 4 * reset_period) / 4; > > } > > +#ifndef CONFIG_WATCHDOG_AUTOSTART > > + printf("WDT: Not starting\n"); > > + return 0; > > +#else > > ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); > > if (ret != 0) { > > printf("WDT: Failed to start\n"); > > @@ -61,6 +67,7 @@ int initr_watchdog(void) > >IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); > > return 0; > > +#endif > > Please use this instead here: > > if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) { > ... > > Thanks, > Stefan > > > } > > int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) > > > > > Viele Grüße, > Stefan I have fixed these issues in V2.
Re: [PATCH u-boot 17/39] build: support building with Link Time Optimizations
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > Add plumbing for building U-Boot with Link Time Optimizations. > > Signed-off-by: Marek Behún > --- > Kbuild | 2 ++ > Kconfig | 19 +++ > Makefile | 36 > scripts/Makefile.lib | 3 +++ > scripts/Makefile.spl | 14 ++ > 5 files changed, 74 insertions(+) > > diff --git a/Kbuild b/Kbuild > index 1eac091594..bf52e54051 100644 > --- a/Kbuild > +++ b/Kbuild > @@ -10,6 +10,8 @@ generic-offsets-file := > include/generated/generic-asm-offsets.h > always := $(generic-offsets-file) > targets := lib/asm-offsets.s > > +CFLAGS_REMOVE_asm-offsets.o := $(LTO_CFLAGS) > + > $(obj)/$(generic-offsets-file): $(obj)/lib/asm-offsets.s FORCE > $(call filechk,offsets,__GENERIC_ASM_OFFSETS_H__) > > diff --git a/Kconfig b/Kconfig > index 86f0a39bb0..ceba53926f 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -85,6 +85,25 @@ config SPL_OPTIMIZE_INLINING > do what it thinks is best, which is desirable in some cases for size > reasons. > > +config ARCH_SUPPORTS_LTO > + bool > + > +config LTO > + bool "Enable Link Time Optimizations" > + depends on ARCH_SUPPORTS_LTO > + default n nits: this line is not needed as the default value is n if omitted > + help > + This option enables Link Time Optimization (LTO), a mechanism which > + allows the compiler to optimize between different compilation units. > + > + This can optimize away dead code paths, resulting in smaller binary > + size (if CC_OPTIMIZE_FOR_SIZE is enabled). > + > + This option is not available for every architecture and may > + introduce bugs. > + > + If unsure, say n. > + > config TPL_OPTIMIZE_INLINING > bool "Allow compiler to uninline functions marked 'inline' in TPL" > depends on TPL > diff --git a/Makefile b/Makefile > index 6dc47810ea..4eee0c4196 100644 > --- a/Makefile > +++ b/Makefile > @@ -677,6 +677,28 @@ else > KBUILD_CFLAGS += -O2 > endif > > +LTO_CFLAGS := > +LTO_FINAL_LDFLAGS := > +export LTO_CFLAGS LTO_FINAL_LDFLAGS > +ifdef CONFIG_LTO > + LTO_CFLAGS := -flto > + LTO_FINAL_LDFLAGS := -fwhole-program This one should not be necessary per my read of the GCC doc. Also in your patch, it is only used in the SPL build. > + > + CFLAGS_NON_EFI += $(LTO_CFLAGS) > + > + ifeq ($(cc-name),clang) > + LTO_FINAL_LDFLAGS += -flto > + else > + LTO_FINAL_LDFLAGS += -fuse-linker-plugin -flto=jobserver > + > + # use plugin aware tools > + AR = $(CROSS_COMPILE)gcc-ar > + NM = $(CROSS_COMPILE)gcc-nm > + endif > + > + KBUILD_CFLAGS += $(LTO_CFLAGS) > +endif > + > KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector) > KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks) > > @@ -1751,6 +1773,19 @@ ARCH_POSTLINK := $(wildcard > $(srctree)/arch/$(ARCH)/Makefile.postlink) > > # Rule to link u-boot > # May be overridden by arch/$(ARCH)/config.mk > +ifdef CONFIG_LTO > +quiet_cmd_u-boot__ ?= LTO $@ > + cmd_u-boot__ ?= > \ > + $(CC) -nostdlib -nostartfiles > \ > + $(LTO_FINAL_CFLAGS) $(c_flags) > \ LTO_FINAL_CFLAGS is not defined anywhere. I guess you wanted to use LTO_FINAL_LDFLAGS? > + $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o $@ > \ > + -T u-boot.lds $(u-boot-init) > \ > + -Wl,--start-group -Wl,--whole-archive > \ --start-group should be dropped > + $(u-boot-main) > \ > + -Wl,--no-whole-archive -Wl,--end-group > \ > + $(PLATFORM_LIBS) -Wl,-Map,u-boot.map; > \ > + $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > +else > quiet_cmd_u-boot__ ?= LD $@ >cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ > \ > -T u-boot.lds $(u-boot-init) > \ > @@ -1759,6 +1794,7 @@ quiet_cmd_u-boot__ ?= LD $@ > --no-whole-archive --end-group > \ > $(PLATFORM_LIBS) -Map u-boot.map; > \ > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true) > +endif > > quiet_cmd_smap = GEN common/system_map.o > cmd_smap = \ > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 78543c6dd1..78bbeb
Re: [PATCH 1/9] ARM: dts: stm32: Add Engicam i.Core STM32MP1 SoM
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. > > General features: > - STM32MP157A > - Up to 1GB DDR3L > - 4GB eMMC > - 10/100 Ethernet > - USB 2.0 Host/OTG > - I2S > - MIPI DSI to LVDS > - rest of STM32MP157A features > > i.Core STM32MP1 needs to mount on top of Engicam baseboards > for creating complete platform solutions. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi | 196 +++ > 1 file changed, 196 insertions(+) > create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi > > diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi > b/arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi > new file mode 100644 > index 00..01166ccacf > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi > @@ -0,0 +1,196 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/ { > + compatible = "engicam,icore-stm32mp1", "st,stm32mp157"; > + > + memory@c000 { > + device_type = "memory"; > + reg = <0xc000 0x2000>; > + }; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + mcuram2: mcuram2@1000 { > + compatible = "shared-dma-pool"; > + reg = <0x1000 0x4>; > + no-map; > + }; > + > + vdev0vring0: vdev0vring0@1004 { > + compatible = "shared-dma-pool"; > + reg = <0x1004 0x1000>; > + no-map; > + }; > + > + vdev0vring1: vdev0vring1@10041000 { > + compatible = "shared-dma-pool"; > + reg = <0x10041000 0x1000>; > + no-map; > + }; > + > + vdev0buffer: vdev0buffer@10042000 { > + compatible = "shared-dma-pool"; > + reg = <0x10042000 0x4000>; > + no-map; > + }; > + > + mcuram: mcuram@3000 { > + compatible = "shared-dma-pool"; > + reg = <0x3000 0x4>; > + no-map; > + }; > + > + retram: retram@3800 { > + compatible = "shared-dma-pool"; > + reg = <0x3800 0x1>; > + no-map; > + }; > + }; > + > + vddcore: regulator-vddcore { > + compatible = "regulator-fixed"; > + regulator-name = "vddcore"; > + regulator-min-microvolt = <120>; > + regulator-max-microvolt = <120>; > + regulator-always-on; > + }; > + > + vdd: regulator-vdd { > + compatible = "regulator-fixed"; > + regulator-name = "vdd"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > + regulator-always-on; > + }; > + > + vdd_usb: regulator-vdd-usb { > + compatible = "regulator-fixed"; > + regulator-name = "vdd_usb"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > + regulator-always-on; > + }; > + > + vdda: regulator-vdda { > + compatible = "regulator-fixed"; > + regulator-name = "vdda"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > + regulator-always-on; > + }; > + > + vdd_ddr: regulator-vdd-ddr { > + compatible = "regulator-fixed"; > + regulator-name = "vdd_ddr"; > + regulator-min-microvolt = <135>; > + regulator-max-microvolt = <135>; > + regulator-always-on; > + }; > + > + vtt_ddr: regulator-vtt-ddr { > + compatible = "regulator-fixed"; > + regulator-name = "vtt_ddr"; > + regulator-min-microvolt = <675000>; > + regulator-max-microvolt = <675000>; > + regulator-always-on; > + vin-supply = <&vdd>; > + }; > + > + vref_ddr: regulator-vref-ddr { > + compatible = "regulator-fixed"; > + regulator-name = "vref_ddr"; > + regulator-min-microvolt = <675000>; > + regulator-max-microvolt = <675000>; > + regulator-always-on; > + vin-supply = <&vdd>; > + }; > + > + vdd_sd: regulator-vdd-sd { > + compatible = "regulator-fixed"; > + regulator-name = "vdd_sd"; > + regulator-min-microvolt = <330>; > + regulator-max-micr
Re: [PATCH 2/9] ARM: dts: stm32: Add Engicam i.Core STM32MP1 1X4Gb DDR3
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > Engicam i.Core STM32MP1 SODIMM SoM has mounted 1x4Gb DDR3 > which has 32bits width 528000Khz frequency. > > Add DDR configuration via dtsi. > > Signed-off-by: Jagan Teki > --- > .../stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi | 119 ++ > 1 file changed, 119 insertions(+) > create mode 100644 arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi > > diff --git a/arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi > b/arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi > new file mode 100644 > index 00..1a45c6fc63 > --- /dev/null > +++ b/arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi > @@ -0,0 +1,119 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause > +/* > + * Copyright (C) 2015-2018, STMicroelectronics - All Rights Reserved > + */ > + > +/* > + * File generated by STMicroelectronics STM32CubeMX DDR Tool for MPUs > + * DDR type: DDR3 / DDR3L > + * DDR width: 32bits > + * DDR density: 4Gb > + * System frequency: 528000Khz > + * Relaxed Timing Mode: false > + * Address mapping type: RBC > + * > + * Save Date: 2019.05.14, save Time: 11:25:16 > + */ > +#define DDR_MEM_COMPATIBLE ddr3-icore-1066-888-bin-g-1x4gb-528mhz > +#define DDR_MEM_NAME "DDR3-DDR3L 32bits 528000Khz" > +#define DDR_MEM_SPEED528000 > +#define DDR_MEM_SIZE 0x2000 > + > +#define DDR_MSTR 0x00040401 > +#define DDR_MRCTRL0 0x0010 > +#define DDR_MRCTRL1 0x > +#define DDR_DERATEEN 0x > +#define DDR_DERATEINT 0x0080 > +#define DDR_PWRCTL 0x > +#define DDR_PWRTMG 0x00400010 > +#define DDR_HWLPCTL 0x > +#define DDR_RFSHCTL0 0x0021 > +#define DDR_RFSHCTL3 0x > +#define DDR_RFSHTMG 0x0080008A > +#define DDR_CRCPARCTL0 0x > +#define DDR_DRAMTMG0 0x121B2414 > +#define DDR_DRAMTMG1 0x000A041B > +#define DDR_DRAMTMG2 0x0607080F > +#define DDR_DRAMTMG3 0x0050400C > +#define DDR_DRAMTMG4 0x07040607 > +#define DDR_DRAMTMG5 0x06060403 > +#define DDR_DRAMTMG6 0x02020002 > +#define DDR_DRAMTMG7 0x0202 > +#define DDR_DRAMTMG8 0x1005 > +#define DDR_DRAMTMG14 0x00A0 > +#define DDR_ZQCTL0 0xC240 > +#define DDR_DFITMG0 0x02050105 > +#define DDR_DFITMG1 0x0202 > +#define DDR_DFILPCFG0 0x0700 > +#define DDR_DFIUPD0 0xC043 > +#define DDR_DFIUPD1 0x > +#define DDR_DFIUPD2 0x > +#define DDR_DFIPHYMSTR 0x > +#define DDR_ODTCFG 0x06000600 > +#define DDR_ODTMAP 0x0001 > +#define DDR_SCHED 0x0C01 > +#define DDR_SCHED1 0x > +#define DDR_PERFHPR1 0x0101 > +#define DDR_PERFLPR1 0x08000200 > +#define DDR_PERFWR1 0x08000400 > +#define DDR_DBG0 0x > +#define DDR_DBG1 0x > +#define DDR_DBGCMD 0x > +#define DDR_POISONCFG 0x > +#define DDR_PCCFG 0x0010 > +#define DDR_PCFGR_0 0x0001 > +#define DDR_PCFGW_0 0x > +#define DDR_PCFGQOS0_0 0x02100C03 > +#define DDR_PCFGQOS1_0 0x00800100 > +#define DDR_PCFGWQOS0_0 0x01100C03 > +#define DDR_PCFGWQOS1_0 0x01000200 > +#define DDR_PCFGR_1 0x0001 > +#define DDR_PCFGW_1 0x > +#define DDR_PCFGQOS0_1 0x02100C03 > +#define DDR_PCFGQOS1_1 0x00800040 > +#define DDR_PCFGWQOS0_1 0x01100C03 > +#define DDR_PCFGWQOS1_1 0x01000200 > +#define DDR_ADDRMAP1 0x00080808 > +#define DDR_ADDRMAP2 0x > +#define DDR_ADDRMAP3 0x > +#define DDR_ADDRMAP4 0x1F1F > +#define DDR_ADDRMAP5 0x07070707 > +#define DDR_ADDRMAP6 0x0F0F0707 > +#define DDR_ADDRMAP9 0x > +#define DDR_ADDRMAP10 0x > +#define DDR_ADDRMAP11 0x > +#define DDR_PGCR 0x01442E02 > +#define DDR_PTR0 0x0022A41B > +#define DDR_PTR1 0x047C0740 > +#define DDR_PTR2 0x042D9C80 > +#define DDR_ACIOCR 0x10400812 > +#define DDR_DXCCR 0x0C40 > +#define DDR_DSGCR 0xF21F > +#define DDR_DCR 0x000B > +#define DDR_DTPR0 0x36D477D0 > +#define DDR_DTPR1 0x098A00D8 > +#define DDR_DTPR2 0x10023600 > +#define DDR_MR0 0x0830 > +#define DDR_MR1 0x > +#define DDR_MR2 0x0208 > +#define DDR_MR3 0x > +#define DDR_ODTCR 0x0001 > +#define DDR_ZQ0CR1 0x0038 > +#define DDR_DX0GCR 0xCE81 > +#define DDR_DX0DLLCR 0x4000 > +#define DDR_DX0DQTR 0x > +#define DDR_DX0DQSTR 0x3DB02000 > +#define DDR_DX1GCR 0xCE81 > +#define DDR_DX1DLLCR 0x4000 > +#define DDR_DX1DQTR 0x > +#define DDR_DX1DQSTR 0x3DB02000 > +#define DDR_DX2GCR 0xCE81 > +#define DDR_DX2DLLCR 0x4000 > +#define DDR_DX2DQTR 0x > +#define DDR_DX2DQSTR 0x3DB02000 > +#define DDR_DX3GCR 0xCE81 > +#define DDR_DX3DLLCR 0x4000 > +#define DDR_DX3DQTR 0x > +#define DDR_DX3DQSTR 0x3DB02000 > + > +#include "stm32mp15-ddr.dtsi" > Reviewed-by: Patrice Chotard Thanks Patrice
[PATCH] rtc: add support for rv3028 rtc
add support for rtc3028 rtc from microcrystal. based on linux dirver: commit a38fd8748464: ("Linux 5.12-rc2") Signed-off-by: Heiko Schocher --- driver is based on code in linux, but with already corrected weekday usage. linux codes the weekday bitwise, while the weekday register has only 3 valid bits as the app manual [1] says: This register holds the current day of the week. Each value represents one weekday that is assigned by the user. Values will range from 0 to 6 The weekday counter is simply a 3-bit counter which counts up to 6 and then resets to 0. [1] https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf This is not a big problem, as userspace never use weekday. Nevertheless, I will also send an update for the linux driver. Also the nvram can be used for bootcounter purposes. Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board. azure build: https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results drivers/rtc/Kconfig | 6 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rv3028.c | 215 +++ 3 files changed, 222 insertions(+) create mode 100644 drivers/rtc/rv3028.c diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index aa6d90158c..e451308b40 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -95,6 +95,12 @@ config RTC_PCF8563 If you say yes here you get support for the Philips PCF8563 RTC and compatible chips. +config RTC_RV3028 + bool "Enable RV3028 driver" + depends on DM_RTC + help + The MicroCrystal RV3028 is a I2C Real Time Clock (RTC) + config RTC_RV3029 bool "Enable RV3029 driver" depends on DM_RTC diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 6a45a9c874..e7acd76266 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o obj-$(CONFIG_RTC_PL031) += pl031.o obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o +obj-$(CONFIG_RTC_RV3028) += rv3028.o obj-$(CONFIG_RTC_RV3029) += rv3029.o obj-$(CONFIG_RTC_RV8803) += rv8803.o obj-$(CONFIG_RTC_RX8025) += rx8025.o diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c new file mode 100644 index 00..8d8336c5f1 --- /dev/null +++ b/drivers/rtc/rv3028.c @@ -0,0 +1,215 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * RTC driver for the Micro Crystal RV3028 + * + * based on linux driver from + * Copyright (C) 2019 Micro Crystal SA + * + * Alexandre Belloni + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RV3028_SEC 0x00 +#define RV3028_MIN 0x01 +#define RV3028_HOUR0x02 +#define RV3028_WDAY0x03 +#define RV3028_DAY 0x04 +#define RV3028_MONTH 0x05 +#define RV3028_YEAR0x06 +#define RV3028_ALARM_MIN 0x07 +#define RV3028_ALARM_HOUR 0x08 +#define RV3028_ALARM_DAY 0x09 +#define RV3028_STATUS 0x0E +#define RV3028_CTRL1 0x0F +#define RV3028_CTRL2 0x10 +#define RV3028_EVT_CTRL0x13 +#define RV3028_TS_COUNT0x14 +#define RV3028_TS_SEC 0x15 +#define RV3028_RAM10x1F +#define RV3028_EEPROM_ADDR 0x25 +#define RV3028_EEPROM_DATA 0x26 +#define RV3028_EEPROM_CMD 0x27 +#define RV3028_CLKOUT 0x35 +#define RV3028_OFFSET 0x36 +#define RV3028_BACKUP 0x37 + +#define RV3028_STATUS_PORF BIT(0) +#define RV3028_STATUS_EVF BIT(1) +#define RV3028_STATUS_AF BIT(2) +#define RV3028_STATUS_TF BIT(3) +#define RV3028_STATUS_UF BIT(4) +#define RV3028_STATUS_BSF BIT(5) +#define RV3028_STATUS_CLKF BIT(6) +#define RV3028_STATUS_EEBUSY BIT(7) + +#define RV3028_CLKOUT_FD_MASK GENMASK(2, 0) +#define RV3028_CLKOUT_PORIEBIT(3) +#define RV3028_CLKOUT_CLKSYBIT(6) +#define RV3028_CLKOUT_CLKOEBIT(7) + +#define RV3028_CTRL1_EERD BIT(3) +#define RV3028_CTRL1_WADA BIT(5) + +#define RV3028_CTRL2_RESET BIT(0) +#define RV3028_CTRL2_12_24 BIT(1) +#define RV3028_CTRL2_EIE BIT(2) +#define RV3028_CTRL2_AIE BIT(3) +#define RV3028_CTRL2_TIE BIT(4) +#define RV3028_CTRL2_UIE BIT(5) +#define RV3028_CTRL2_TSE BIT(7) + +#define RV3028_EVT_CTRL_TSRBIT(2) + +#define RV3028_EEPROM_CMD_UPDATE 0x11 +#define RV3028_EEPROM_CMD_WRITE0x21 +#define RV3028_EEPROM_CMD_READ 0x22 + +#define RV3028_EEBUSY_POLL 1 +#define RV3028_E
Re: [PATCH 3/9] ARM: stm32: Imply SPL_SPI_LOAD
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > SPI Load isn't mandatory for STM32 builds. > > Let's imply instead of select it to get rid of build > issues for non-SPI defconfigs. > > Signed-off-by: Jagan Teki > --- > arch/arm/mach-stm32mp/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig > index f538d7cb83..79ffd5191d 100644 > --- a/arch/arm/mach-stm32mp/Kconfig > +++ b/arch/arm/mach-stm32mp/Kconfig > @@ -16,13 +16,13 @@ config SPL > select SPL_REGMAP > select SPL_DM_RESET > select SPL_SERIAL_SUPPORT > - select SPL_SPI_LOAD > select SPL_SYSCON > select SPL_WATCHDOG_SUPPORT if WATCHDOG > imply BOOTSTAGE_STASH if SPL_BOOTSTAGE > imply SPL_BOOTSTAGE if BOOTSTAGE > imply SPL_DISPLAY_PRINT > imply SPL_LIBDISK_SUPPORT > + imply SPL_SPI_LOAD > > config SYS_SOC > default "stm32mp" > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
On Mon, Mar 08, 2021 at 07:50:59AM +0100, Stefan Roese wrote: > On 08.03.21 07:45, Marek Behun wrote: > > > Reviewed-by: Stefan Roese > > > > Thanks, Stefan. > > Do you want to merge this into your repo u-boot-marvell, or shall Tom > > merge this once this series is mature? > > AFAIU, your patch series touches many architectures / platforms. It' > currently assigned to Tom in patchwork and it perhaps makes more sense > to pull it as one patchset. > > If it is preferred that I shall pull the 2 Marvell related patches > via the Marvell repo, I can definitely do so. But for now I'm waiting > for Tom to handle this. If it's not exposing problems prior to LTO, I'll take it as the series, if it's exposing problems today and it should go in now rather than for v2021.07, please pick it up for the marvell tree. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/9] board: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
Hi Jagan one remark below On 2/28/21 4:52 PM, Jagan Teki wrote: > Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive > Evaluation Board. > > Genaral features: > - LCD 7" C.Touch > - microSD slot > - Ethernet 1Gb > - Wifi/BT > - 2x LVDS Full HD interfaces > - 3x USB 2.0 > - 1x USB 3.0 > - HDMI Out > - Mini PCIe > - MIPI CSI > - 2x CAN > - Audio Out > > i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. > > i.Core STM32MP1 needs to mount on top of this Evaluation board for > creating complete i.Core STM32MP1 EDIMM2.2 Starter Kit. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > arch/arm/dts/Makefile | 1 + > ...mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi | 51 ++ > .../stm32mp157a-icore-stm32mp1-edimm2.2.dts | 47 ++ > .../stm32mp157a-icore-stm32mp1-u-boot.dtsi| 146 ++ > arch/arm/mach-stm32mp/Kconfig | 20 +++ > board/engicam/stm32mp1/Kconfig| 12 ++ > board/engicam/stm32mp1/MAINTAINERS| 6 + > board/engicam/stm32mp1/Makefile | 10 ++ > board/engicam/stm32mp1/spl.c | 48 ++ > board/engicam/stm32mp1/stm32mp1.c | 131 > ...tm32mp15-icore-stm32mp1-edimm2.2_defconfig | 80 ++ > 11 files changed, 552 insertions(+) > create mode 100644 > arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi > create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts > create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-u-boot.dtsi > create mode 100644 board/engicam/stm32mp1/Kconfig > create mode 100644 board/engicam/stm32mp1/MAINTAINERS > create mode 100644 board/engicam/stm32mp1/Makefile > create mode 100644 board/engicam/stm32mp1/spl.c > create mode 100644 board/engicam/stm32mp1/stm32mp1.c > create mode 100644 configs/stm32mp15-icore-stm32mp1-edimm2.2_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index f478f6f18f..f4a48c65e8 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -979,6 +979,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb > dtb-$(CONFIG_STM32MP15x) += \ > stm32mp157a-dk1.dtb \ > stm32mp157a-avenger96.dtb \ > + stm32mp157a-icore-stm32mp1-edimm2.2.dtb \ > stm32mp157c-dk2.dtb \ > stm32mp157c-ed1.dtb \ > stm32mp157c-ev1.dtb \ > diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi > b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi > new file mode 100644 > index 00..96fe461235 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi > @@ -0,0 +1,51 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Amarula Solutions(India) > + * Author: Jagan Teki > + */ > + > +#include "stm32mp157a-icore-stm32mp1-u-boot.dtsi" > + > +/{ > + aliases { > + mmc0 = &sdmmc1; > + }; > + > + chosen { > + stdout-path = &uart4; > + }; > +}; > + > +&sdmmc1 { > + u-boot,dm-pre-reloc; > +}; > + > +&sdmmc1_b4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + }; > +}; > + > +&uart4 { > + u-boot,dm-pre-reloc; > +}; > + > +&uart4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + bias-pull-up; > + }; > +}; > diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts > b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts > new file mode 100644 > index 00..ec9f1d1cd5 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts > @@ -0,0 +1,47 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/dts-v1/; > +#include "stm32mp157.dtsi" > +#include "stm32mp157a-icore-stm32mp1.dtsi" > +#include "stm32mp15-pinctrl.dtsi" > +#include "stm32mp15xxaa-pinctrl.dtsi" > +#include > + > +/ { > + model = "Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit"; > + compatible = "engicam,icore-stm32mp1-edimm2.2", > + "engicam,icore-stm32mp1", "st,stm32mp157"; > + > + aliases { > + serial0 = &uart4; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > +}; > + > +&sdmmc1 { > + bus-width = <4>; > + disable-wp; > + pinctrl-names = "default", "opendrain", "sleep"; > + pinctrl-0 = <&sdmmc1_b4_pins_a>; > + pinctrl-1 = <&sdmmc1_b4_od_pins_a>; > + pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>; > + st,neg-edge; > + vmmc-supply = <&v3v3>; > + statu
Re: [PATCH 5/9] board: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose Carrier > board. > > Genaral features: > - Ethernet 10/100 > - Wifi/BT > - USB Type A/OTG > - Audio Out > - CAN > - LVDS panel connector > > i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. > > i.Core STM32MP1 needs to mount on top of this Carrier board for > creating complete i.Core STM32MP1 C.TOUCH 2.0 board. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > arch/arm/dts/Makefile | 1 + > ...2mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi | 51 > .../stm32mp157a-icore-stm32mp1-ctouch2.dts| 47 +++ > arch/arm/mach-stm32mp/Kconfig | 5 ++ > board/engicam/stm32mp1/MAINTAINERS| 6 ++ > ...stm32mp15-icore-stm32mp1-ctouch2_defconfig | 80 +++ > 6 files changed, 190 insertions(+) > create mode 100644 > arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi > create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts > create mode 100644 configs/stm32mp15-icore-stm32mp1-ctouch2_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index f4a48c65e8..7e0fae8cf0 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -979,6 +979,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb > dtb-$(CONFIG_STM32MP15x) += \ > stm32mp157a-dk1.dtb \ > stm32mp157a-avenger96.dtb \ > + stm32mp157a-icore-stm32mp1-ctouch2.dtb \ > stm32mp157a-icore-stm32mp1-edimm2.2.dtb \ > stm32mp157c-dk2.dtb \ > stm32mp157c-ed1.dtb \ > diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi > b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi > new file mode 100644 > index 00..96fe461235 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi > @@ -0,0 +1,51 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Amarula Solutions(India) > + * Author: Jagan Teki > + */ > + > +#include "stm32mp157a-icore-stm32mp1-u-boot.dtsi" > + > +/{ > + aliases { > + mmc0 = &sdmmc1; > + }; > + > + chosen { > + stdout-path = &uart4; > + }; > +}; > + > +&sdmmc1 { > + u-boot,dm-pre-reloc; > +}; > + > +&sdmmc1_b4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + }; > +}; > + > +&uart4 { > + u-boot,dm-pre-reloc; > +}; > + > +&uart4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + bias-pull-up; > + }; > +}; > diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts > b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts > new file mode 100644 > index 00..d3058a036c > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts > @@ -0,0 +1,47 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/dts-v1/; > +#include "stm32mp157.dtsi" > +#include "stm32mp157a-icore-stm32mp1.dtsi" > +#include "stm32mp15-pinctrl.dtsi" > +#include "stm32mp15xxaa-pinctrl.dtsi" > +#include > + > +/ { > + model = "Engicam i.Core STM32MP1 C.TOUCH 2.0"; > + compatible = "engicam,icore-stm32mp1-ctouch2", > + "engicam,icore-stm32mp1", "st,stm32mp157"; > + > + aliases { > + serial0 = &uart4; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > +}; > + > +&sdmmc1 { > + bus-width = <4>; > + disable-wp; > + pinctrl-names = "default", "opendrain", "sleep"; > + pinctrl-0 = <&sdmmc1_b4_pins_a>; > + pinctrl-1 = <&sdmmc1_b4_od_pins_a>; > + pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>; > + st,neg-edge; > + vmmc-supply = <&v3v3>; > + status = "okay"; > +}; > + > +&uart4 { > + pinctrl-names = "default", "sleep", "idle"; > + pinctrl-0 = <&uart4_pins_a>; > + pinctrl-1 = <&uart4_sleep_pins_a>; > + pinctrl-2 = <&uart4_idle_pins_a>; > + status = "okay"; > +}; > diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig > index 5a2123063a..15c832b16b 100644 > --- a/arch/arm/mach-stm32mp/Kconfig > +++ b/arch/arm/mach-stm32mp/Kconfig > @@ -96,6 +96,11 @@ config TARGET_ICORE_STM32MP1 > * i.Core STM32MP1 needs to mount on top of EDIMM2.2 for > creating complete i.Core STM32MP1 EDIMM2.2 Starter Kit. > > + i.Core STM32MP1 C.TOUCH 2.0 > + * C.TOUCH 2.0 is a general purpose Carrier board. > + * i.Core STM32MP1 needs to mount on top of this Carrier boar
Re: [PATCH 6/9] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 Micro SoM
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > MicroGEA STM32MP1 is a STM32MP157A based Micro SoM. > > General features: > - STM32MP157AAC > - Up to 1GB DDR3L-800 > - 512MB Nand flash > - I2S > > MicroGEA STM32MP1 needs to mount on top of Engicam MicroDev carrier > boards for creating complete platform solutions. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > .../dts/stm32mp157a-microgea-stm32mp1.dtsi| 148 ++ > 1 file changed, 148 insertions(+) > create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi > > diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi > new file mode 100644 > index 00..0b85175f15 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi > @@ -0,0 +1,148 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/ { > + compatible = "engicam,microgea-stm32mp1", "st,stm32mp157"; > + > + memory@c000 { > + device_type = "memory"; > + reg = <0xc000 0x1000>; > + }; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + mcuram2: mcuram2@1000 { > + compatible = "shared-dma-pool"; > + reg = <0x1000 0x4>; > + no-map; > + }; > + > + vdev0vring0: vdev0vring0@1004 { > + compatible = "shared-dma-pool"; > + reg = <0x1004 0x1000>; > + no-map; > + }; > + > + vdev0vring1: vdev0vring1@10041000 { > + compatible = "shared-dma-pool"; > + reg = <0x10041000 0x1000>; > + no-map; > + }; > + > + vdev0buffer: vdev0buffer@10042000 { > + compatible = "shared-dma-pool"; > + reg = <0x10042000 0x4000>; > + no-map; > + }; > + > + mcuram: mcuram@3000 { > + compatible = "shared-dma-pool"; > + reg = <0x3000 0x4>; > + no-map; > + }; > + > + retram: retram@3800 { > + compatible = "shared-dma-pool"; > + reg = <0x3800 0x1>; > + no-map; > + }; > + }; > + > + vin: regulator-vin { > + compatible = "regulator-fixed"; > + regulator-name = "vin"; > + regulator-min-microvolt = <500>; > + regulator-max-microvolt = <500>; > + regulator-always-on; > + }; > + > + vddcore: regulator-vddcore { > + compatible = "regulator-fixed"; > + regulator-name = "vddcore"; > + regulator-min-microvolt = <120>; > + regulator-max-microvolt = <120>; > + regulator-always-on; > + vin-supply = <&vin>; > + }; > + > + vdd: regulator-vdd { > + compatible = "regulator-fixed"; > + regulator-name = "vdd"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > + regulator-always-on; > + vin-supply = <&vin>; > + }; > + > + vddq_ddr: regulator-vddq-ddr { > + compatible = "regulator-fixed"; > + regulator-name = "vddq_ddr"; > + regulator-min-microvolt = <135>; > + regulator-max-microvolt = <135>; > + regulator-always-on; > + vin-supply = <&vin>; > + }; > +}; > + > +&dts { > + status = "okay"; > +}; > + > +&fmc { > + pinctrl-names = "default", "sleep"; > + pinctrl-0 = <&fmc_pins_a>; > + pinctrl-1 = <&fmc_sleep_pins_a>; > + status = "okay"; > + > + nand-controller@4,0 { > + status = "okay"; > + > + nand@0 { > + reg = <0>; > + nand-on-flash-bbt; > + #address-cells = <1>; > + #size-cells = <1>; > + }; > + }; > +}; > + > +&ipcc { > + status = "okay"; > +}; > + > +&iwdg2{ > + timeout-sec = <32>; > + status = "okay"; > +}; > + > +&m4_rproc{ > + memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>, > + <&vdev0vring1>, <&vdev0buffer>; > + mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>; > + mbox-names = "vq0", "vq1", "shutdown"; > + interrupt-parent = <&exti>; > + interrupts = <68 1>; > + status = "okay"; > +}; > + > +&rng1 { > + status = "okay"; > +}; > + > +&rtc{ > + status = "okay"; > +}; > + > +&vrefbuf { > + regulator-min-microv
Re: [PATCH 7/9] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 1X4Gb DDR3
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > Engicam MicroGEA STM32MP1 Micro SOM has mounted 1x4Gb DDR3 > which has 16bits width 533Mhz frequency. > > Add DDR configurations via dtsi. > > Signed-off-by: Jagan Teki > --- > ...m32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi | 121 ++ > 1 file changed, 121 insertions(+) > create mode 100644 arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi > > diff --git a/arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi > b/arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi > new file mode 100644 > index 00..950f292abb > --- /dev/null > +++ b/arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi > @@ -0,0 +1,121 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause > +/* > + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved > + * > + * STM32MP157C DK1/DK2 BOARD configuration > + * 1x DDR3L 4Gb, 16-bit, 533MHz. > + * Reference used NT5CC256M16DP-DI from NANYA > + * > + * DDR type / Platform DDR3/3L > + * freq 533MHz > + * width 16 > + * datasheet 0 = MT41J256M16-187 / DDR3-1066 bin G > + * DDR density 4 > + * timing mode optimized > + * Scheduling/QoS options : type = 2 > + * address mapping : RBC > + * Tc > + 85C : N > + */ > +#define DDR_MEM_COMPATIBLE ddr3-microgea-1066-888-bin-g-1x4gb-533mhz > +#define DDR_MEM_NAME "DDR3-1066/888 bin G 1x4Gb 533MHz v1.45" > +#define DDR_MEM_SPEED 533000 > +#define DDR_MEM_SIZE 0x2000 > + > +#define DDR_MSTR 0x00041401 > +#define DDR_MRCTRL0 0x0010 > +#define DDR_MRCTRL1 0x > +#define DDR_DERATEEN 0x > +#define DDR_DERATEINT 0x0080 > +#define DDR_PWRCTL 0x > +#define DDR_PWRTMG 0x00400010 > +#define DDR_HWLPCTL 0x > +#define DDR_RFSHCTL0 0x0021 > +#define DDR_RFSHCTL3 0x > +#define DDR_RFSHTMG 0x0081008B > +#define DDR_CRCPARCTL0 0x > +#define DDR_DRAMTMG0 0x121B2414 > +#define DDR_DRAMTMG1 0x000A041C > +#define DDR_DRAMTMG2 0x0608090F > +#define DDR_DRAMTMG3 0x0050400C > +#define DDR_DRAMTMG4 0x08040608 > +#define DDR_DRAMTMG5 0x06060403 > +#define DDR_DRAMTMG6 0x02020002 > +#define DDR_DRAMTMG7 0x0202 > +#define DDR_DRAMTMG8 0x1005 > +#define DDR_DRAMTMG14 0x00A0 > +#define DDR_ZQCTL0 0xC240 > +#define DDR_DFITMG0 0x02060105 > +#define DDR_DFITMG1 0x0202 > +#define DDR_DFILPCFG0 0x0700 > +#define DDR_DFIUPD0 0xC043 > +#define DDR_DFIUPD1 0x > +#define DDR_DFIUPD2 0x > +#define DDR_DFIPHYMSTR 0x > +#define DDR_ADDRMAP1 0x00070707 > +#define DDR_ADDRMAP2 0x > +#define DDR_ADDRMAP3 0x1F00 > +#define DDR_ADDRMAP4 0x1F1F > +#define DDR_ADDRMAP5 0x06060606 > +#define DDR_ADDRMAP6 0x0F060606 > +#define DDR_ADDRMAP9 0x > +#define DDR_ADDRMAP10 0x > +#define DDR_ADDRMAP11 0x > +#define DDR_ODTCFG 0x06000600 > +#define DDR_ODTMAP 0x0001 > +#define DDR_SCHED 0x0C01 > +#define DDR_SCHED1 0x > +#define DDR_PERFHPR1 0x0101 > +#define DDR_PERFLPR1 0x08000200 > +#define DDR_PERFWR1 0x08000400 > +#define DDR_DBG0 0x > +#define DDR_DBG1 0x > +#define DDR_DBGCMD 0x > +#define DDR_POISONCFG 0x > +#define DDR_PCCFG 0x0010 > +#define DDR_PCFGR_0 0x0001 > +#define DDR_PCFGW_0 0x > +#define DDR_PCFGQOS0_0 0x02100C03 > +#define DDR_PCFGQOS1_0 0x00800100 > +#define DDR_PCFGWQOS0_0 0x01100C03 > +#define DDR_PCFGWQOS1_0 0x01000200 > +#define DDR_PCFGR_1 0x0001 > +#define DDR_PCFGW_1 0x > +#define DDR_PCFGQOS0_1 0x02100C03 > +#define DDR_PCFGQOS1_1 0x00800040 > +#define DDR_PCFGWQOS0_1 0x01100C03 > +#define DDR_PCFGWQOS1_1 0x01000200 > +#define DDR_PGCR 0x01442E02 > +#define DDR_PTR0 0x0022AA5B > +#define DDR_PTR1 0x04841104 > +#define DDR_PTR2 0x042DA068 > +#define DDR_ACIOCR 0x10400812 > +#define DDR_DXCCR 0x0C40 > +#define DDR_DSGCR 0xF200011F > +#define DDR_DCR 0x000B > +#define DDR_DTPR0 0x38D488D0 > +#define DDR_DTPR1 0x098B00D8 > +#define DDR_DTPR2 0x10023600 > +#define DDR_MR0 0x0840 > +#define DDR_MR1 0x > +#define DDR_MR2 0x0208 > +#define DDR_MR3 0x > +#define DDR_ODTCR 0x0001 > +#define DDR_ZQ0CR1 0x0038 > +#define DDR_DX0GCR 0xCE81 > +#define DDR_DX0DLLCR 0x4000 > +#define DDR_DX0DQTR 0x > +#define DDR_DX0DQSTR 0x3DB02000 > +#define DDR_DX1GCR 0xCE81 > +#define DDR_DX1DLLCR 0x4000 > +#define DDR_DX1DQTR 0x > +#define DDR_DX1DQSTR 0x3DB02000 > +#define DDR_DX2GCR 0xCE80 > +#define DDR_DX2DLLCR 0x4000 > +#define DDR_DX2DQTR 0x > +#define DDR_DX2DQSTR 0x3DB02000 > +#define DDR_DX3GCR 0xCE80 > +#define DDR_DX3DLLCR 0x4000 > +#define DDR_DX3DQTR 0x > +#define DDR_DX3DQSTR 0x3DB02000 > + > +#include "stm32mp15-ddr.dtsi" > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 8/9] board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 board
Hi Jagan one minor remard below On 2/28/21 4:52 PM, Jagan Teki wrote: > MicroDev 2.0 is a general purpose miniature carrier board with CAN, > LTE and LVDS panel interfaces. > > Genaral features: > - Ethernet 10/100 > - USB Type A > - Audio Out > - microSD > - LVDS panel connector > - Wifi/BT (option) > - UMTS LTE with sim connector (option) > > MicroGEA STM32MP1 is a STM32MP157A based Micro SoM. > > MicroGEA STM32MP1 needs to mount on top of this MicroDev 2.0 board > for creating complete MicroGEA STM32MP1 MicroDev 2.0 Carrier board. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > arch/arm/dts/Makefile | 1 + > ...-microgea-stm32mp1-microdev2.0-u-boot.dtsi | 51 > ...32mp157a-microgea-stm32mp1-microdev2.0.dts | 55 > .../stm32mp157a-microgea-stm32mp1-u-boot.dtsi | 118 ++ > arch/arm/mach-stm32mp/Kconfig | 20 +++ > board/engicam/stm32mp1/Kconfig| 2 +- > board/engicam/stm32mp1/MAINTAINERS| 6 + > ...mp15-microgea-stm32mp1-microdev2_defconfig | 80 > 8 files changed, 332 insertions(+), 1 deletion(-) > create mode 100644 > arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi > create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts > create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-u-boot.dtsi > create mode 100644 configs/stm32mp15-microgea-stm32mp1-microdev2_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 7e0fae8cf0..7b275fe46c 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -979,6 +979,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb > dtb-$(CONFIG_STM32MP15x) += \ > stm32mp157a-dk1.dtb \ > stm32mp157a-avenger96.dtb \ > + stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \ follow alphabetical order, should be located below stm32mp157a-icore-stm32mp1-edimm2.2.dtb > stm32mp157a-icore-stm32mp1-ctouch2.dtb \ > stm32mp157a-icore-stm32mp1-edimm2.2.dtb \ > stm32mp157c-dk2.dtb \ > diff --git > a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi > new file mode 100644 > index 00..e4bd215812 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi > @@ -0,0 +1,51 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Amarula Solutions(India) > + * Author: Jagan Teki > + */ > + > +#include "stm32mp157a-microgea-stm32mp1-u-boot.dtsi" > + > +/{ > + aliases { > + mmc0 = &sdmmc1; > + }; > + > + chosen { > + stdout-path = &uart4; > + }; > +}; > + > +&sdmmc1 { > + u-boot,dm-pre-reloc; > +}; > + > +&sdmmc1_b4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + }; > +}; > + > +&uart4 { > + u-boot,dm-pre-reloc; > +}; > + > +&uart4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + bias-pull-up; > + }; > +}; > diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts > new file mode 100644 > index 00..7a75868164 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts > @@ -0,0 +1,55 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/dts-v1/; > +#include "stm32mp157.dtsi" > +#include "stm32mp157a-microgea-stm32mp1.dtsi" > +#include "stm32mp15-pinctrl.dtsi" > +#include "stm32mp15xxaa-pinctrl.dtsi" > +#include > + > +/ { > + model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 Carrier Board"; > + compatible = "engicam,microgea-stm32mp1-microdev2.0", > + "engicam,microgea-stm32mp1", "st,stm32mp157"; > + > + aliases { > + serial0 = &uart4; > + serial1 = &uart8; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > +}; > + > +&sdmmc1 { > + bus-width = <4>; > + disable-wp; > + pinctrl-names = "default", "opendrain", "sleep"; > + pinctrl-0 = <&sdmmc1_b4_pins_a>; > + pinctrl-1 = <&sdmmc1_b4_od_pins_a>; > + pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>; > + st,neg-edge; > + vmmc-supply = <&vdd>; > + status = "okay"; > +}; > + > +&uart4 { > + pinctrl-names = "default", "sleep", "idle"; > + pinctrl-0 = <&uart4_pins_a>; > + pinctrl-1 = <&uart4_sleep_pins_a>; > + pinctrl-2 = <&uart4_idle_pins_a>; > + s
Re: [PATCH 9/9] board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > 7" OF is a capacitive touch 7" Open Frame panel solutions with > - 7" AUO B101AW03 LVDS panel > - EDT, FT5526 Touch > > MicroGEA STM32MP1 is a STM32MP157A based Micro SoM. > > MicroDev 2.0 is a general purpose miniature carrier board with CAN, > LTE and LVDS panel interfaces. > > MicroGEA STM32MP1 needs to mount on top of MicroDev 2.0 board with > pluged 7" OF for creating complete MicroGEA STM32MP1 MicroDev 2.0 > 7" Open Frame Solution board. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > arch/arm/dts/Makefile | 1 + > ...rogea-stm32mp1-microdev2.0-of7-u-boot.dtsi | 51 ++ > ...157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 ++ > arch/arm/mach-stm32mp/Kconfig | 7 + > board/engicam/stm32mp1/MAINTAINERS| 6 + > ...-microgea-stm32mp1-microdev2-of7_defconfig | 80 + > 6 files changed, 299 insertions(+) > create mode 100644 > arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > create mode 100644 > arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > create mode 100644 > configs/stm32mp15-microgea-stm32mp1-microdev2-of7_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 7b275fe46c..7a9a05310d 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -980,6 +980,7 @@ dtb-$(CONFIG_STM32MP15x) += \ > stm32mp157a-dk1.dtb \ > stm32mp157a-avenger96.dtb \ > stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \ > + stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \ > stm32mp157a-icore-stm32mp1-ctouch2.dtb \ > stm32mp157a-icore-stm32mp1-edimm2.2.dtb \ > stm32mp157c-dk2.dtb \ > diff --git > a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > new file mode 100644 > index 00..e4bd215812 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > @@ -0,0 +1,51 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Amarula Solutions(India) > + * Author: Jagan Teki > + */ > + > +#include "stm32mp157a-microgea-stm32mp1-u-boot.dtsi" > + > +/{ > + aliases { > + mmc0 = &sdmmc1; > + }; > + > + chosen { > + stdout-path = &uart4; > + }; > +}; > + > +&sdmmc1 { > + u-boot,dm-pre-reloc; > +}; > + > +&sdmmc1_b4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + }; > +}; > + > +&uart4 { > + u-boot,dm-pre-reloc; > +}; > + > +&uart4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + bias-pull-up; > + }; > +}; > diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > new file mode 100644 > index 00..674b2d330d > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > @@ -0,0 +1,154 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/dts-v1/; > +#include "stm32mp157.dtsi" > +#include "stm32mp157a-microgea-stm32mp1.dtsi" > +#include "stm32mp15-pinctrl.dtsi" > +#include "stm32mp15xxaa-pinctrl.dtsi" > +#include > + > +/ { > + model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 7\" Open Frame"; > + compatible = "engicam,microgea-stm32mp1-microdev2.0-of7", > + "engicam,microgea-stm32mp1", "st,stm32mp157"; > + > + aliases { > + serial0 = &uart4; > + serial1 = &uart8; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + backlight: backlight { > + compatible = "gpio-backlight"; > + gpios = <&gpiod 13 GPIO_ACTIVE_HIGH>; > + default-on; > + }; > + > + lcd_3v3: regulator-lcd-3v3 { > + compatible = "regulator-fixed"; > + regulator-name = "lcd_3v3"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > + gpio = <&gpiof 10 GPIO_ACTIVE_HIGH>; > + enable-active-high; > + regulator-always-on; > + power-supply = <&panel_pwr>; > + }; > + > + panel_pwr: regulator-panel-pwr { > + compatible = "regulator-fixed"; > + regulator-name = "panel_pwr"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <33000
Re: [PATCH 9/9] board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
Hi Jagan On 2/28/21 4:52 PM, Jagan Teki wrote: > 7" OF is a capacitive touch 7" Open Frame panel solutions with > - 7" AUO B101AW03 LVDS panel > - EDT, FT5526 Touch > > MicroGEA STM32MP1 is a STM32MP157A based Micro SoM. > > MicroDev 2.0 is a general purpose miniature carrier board with CAN, > LTE and LVDS panel interfaces. > > MicroGEA STM32MP1 needs to mount on top of MicroDev 2.0 board with > pluged 7" OF for creating complete MicroGEA STM32MP1 MicroDev 2.0 > 7" Open Frame Solution board. > > Add support for it. > > Signed-off-by: Jagan Teki > --- > arch/arm/dts/Makefile | 1 + > ...rogea-stm32mp1-microdev2.0-of7-u-boot.dtsi | 51 ++ > ...157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 ++ > arch/arm/mach-stm32mp/Kconfig | 7 + > board/engicam/stm32mp1/MAINTAINERS| 6 + > ...-microgea-stm32mp1-microdev2-of7_defconfig | 80 + > 6 files changed, 299 insertions(+) > create mode 100644 > arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > create mode 100644 > arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > create mode 100644 > configs/stm32mp15-microgea-stm32mp1-microdev2-of7_defconfig > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 7b275fe46c..7a9a05310d 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -980,6 +980,7 @@ dtb-$(CONFIG_STM32MP15x) += \ > stm32mp157a-dk1.dtb \ > stm32mp157a-avenger96.dtb \ > stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \ > + stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \ > stm32mp157a-icore-stm32mp1-ctouch2.dtb \ > stm32mp157a-icore-stm32mp1-edimm2.2.dtb \ > stm32mp157c-dk2.dtb \ > diff --git > a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > new file mode 100644 > index 00..e4bd215812 > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi > @@ -0,0 +1,51 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Amarula Solutions(India) > + * Author: Jagan Teki > + */ > + > +#include "stm32mp157a-microgea-stm32mp1-u-boot.dtsi" > + > +/{ > + aliases { > + mmc0 = &sdmmc1; > + }; > + > + chosen { > + stdout-path = &uart4; > + }; > +}; > + > +&sdmmc1 { > + u-boot,dm-pre-reloc; > +}; > + > +&sdmmc1_b4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + }; > +}; > + > +&uart4 { > + u-boot,dm-pre-reloc; > +}; > + > +&uart4_pins_a { > + u-boot,dm-pre-reloc; > + > + pins1 { > + u-boot,dm-pre-reloc; > + }; > + > + pins2 { > + u-boot,dm-pre-reloc; > + bias-pull-up; > + }; > +}; > diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > new file mode 100644 > index 00..674b2d330d > --- /dev/null > +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts > @@ -0,0 +1,154 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved > + * Copyright (c) 2020 Engicam srl > + * Copyright (c) 2020 Amarula Solutons(India) > + */ > + > +/dts-v1/; > +#include "stm32mp157.dtsi" > +#include "stm32mp157a-microgea-stm32mp1.dtsi" > +#include "stm32mp15-pinctrl.dtsi" > +#include "stm32mp15xxaa-pinctrl.dtsi" > +#include > + > +/ { > + model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 7\" Open Frame"; > + compatible = "engicam,microgea-stm32mp1-microdev2.0-of7", > + "engicam,microgea-stm32mp1", "st,stm32mp157"; > + > + aliases { > + serial0 = &uart4; > + serial1 = &uart8; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + backlight: backlight { > + compatible = "gpio-backlight"; > + gpios = <&gpiod 13 GPIO_ACTIVE_HIGH>; > + default-on; > + }; > + > + lcd_3v3: regulator-lcd-3v3 { > + compatible = "regulator-fixed"; > + regulator-name = "lcd_3v3"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > + gpio = <&gpiof 10 GPIO_ACTIVE_HIGH>; > + enable-active-high; > + regulator-always-on; > + power-supply = <&panel_pwr>; > + }; > + > + panel_pwr: regulator-panel-pwr { > + compatible = "regulator-fixed"; > + regulator-name = "panel_pwr"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <33000
Re: [PATCH] board: stm32mp1: use CONFIG_SYS_MMC_ENV_DEV when available
Hi Patrick On 3/1/21 1:17 PM, Patrick Delaunay wrote: > Check whether user has explicitly defined the mmc device to use > in mmc_get_env_dev() with CONFIG_SYS_MMC_ENV_DEV. > > On STMicroelectronics boards the used mmc device for environment is > the instance of boot device provided by the ROM code; the mmc instance > is configured by alias in device tree. The used partition is defined in > device tree with u-boot,mmc-env-partition = "ssbl". > > This patch allows to override this selection for the support of customer > boards without alias; for example when SDMMC1 is not used and ENV in > mmc0=SDMMC2, user can force the value: CONFIG_SYS_MMC_ENV_DEV = 0. > > On STMicroelectronics boards, the current behavior is kept with > CONFIG_SYS_MMC_ENV_DEV = -1. > > Signed-off-by: Patrick Delaunay > --- > > board/st/stm32mp1/stm32mp1.c| 8 +++- > configs/stm32mp15_basic_defconfig | 1 + > configs/stm32mp15_trusted_defconfig | 1 + > 3 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c > index ab85d8ba68..759181fb5d 100644 > --- a/board/st/stm32mp1/stm32mp1.c > +++ b/board/st/stm32mp1/stm32mp1.c > @@ -862,8 +862,14 @@ const char *env_ext4_get_dev_part(void) > > int mmc_get_env_dev(void) > { > - u32 bootmode = get_bootmode(); > + u32 bootmode; > + > + if (CONFIG_SYS_MMC_ENV_DEV >= 0) > + return CONFIG_SYS_MMC_ENV_DEV; > + > + bootmode = get_bootmode(); > > + /* use boot instance to select the correct mmc device identifier */ > return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1; > } > > diff --git a/configs/stm32mp15_basic_defconfig > b/configs/stm32mp15_basic_defconfig > index 1c680984b8..a2f745099e 100644 > --- a/configs/stm32mp15_basic_defconfig > +++ b/configs/stm32mp15_basic_defconfig > @@ -71,6 +71,7 @@ CONFIG_ENV_UBI_PART="UBI" > CONFIG_ENV_UBI_VOLUME="uboot_config" > CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r" > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SYS_MMC_ENV_DEV=-1 > # CONFIG_SPL_ENV_IS_NOWHERE is not set > # CONFIG_SPL_ENV_IS_IN_SPI_FLASH is not set > CONFIG_STM32_ADC=y > diff --git a/configs/stm32mp15_trusted_defconfig > b/configs/stm32mp15_trusted_defconfig > index 107041119f..f41aaa750f 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -52,6 +52,7 @@ CONFIG_ENV_UBI_PART="UBI" > CONFIG_ENV_UBI_VOLUME="uboot_config" > CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r" > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SYS_MMC_ENV_DEV=-1 > CONFIG_STM32_ADC=y > CONFIG_SET_DFU_ALT_INFO=y > CONFIG_USB_FUNCTION_FASTBOOT=y > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH] video: stm32: remove all child of DSI bridge when its probe failed
Hi Patrick On 3/4/21 1:10 PM, Patrick Delaunay wrote: > From: Patrick Delaunay > > Remove the child device of the STM32 DSI bridge when the driver probe > failed to stop futher probe request on panels used with STMicroelectronics > board (orisetech_otm8009a.c or raydium-rm68200.c driver). > > This patch avoid the trace "cannot get reset GPIO" when > STM32MP157 device tree is used on stm32MP151 SOC without DSI support. > > In this hw_version value is 0, as DSI bridge is absent and the panel > ofdata_to_platdata is called for each try of panel probe, > the gpio reset pin is requested but after dsi father probe failed). > > For the next request, the PANEL ofdata_to_platdata failed as the gpio > is already used. > > Signed-off-by: Patrick Delaunay > Signed-off-by: Patrick Delaunay > --- > > drivers/video/stm32/stm32_dsi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c > index 8891ca4b78..4027e978c8 100644 > --- a/drivers/video/stm32/stm32_dsi.c > +++ b/drivers/video/stm32/stm32_dsi.c > @@ -483,6 +483,9 @@ static int stm32_dsi_probe(struct udevice *dev) > if (priv->hw_version != HWVER_130 && > priv->hw_version != HWVER_131) { > dev_err(dev, "DSI version 0x%x not supported\n", > priv->hw_version); > + dev_dbg(dev, "remove and unbind all DSI child\n"); > + device_chld_remove(dev, NULL, DM_REMOVE_NORMAL); > + device_chld_unbind(dev, NULL); > ret = -ENODEV; > goto err_clk; > } > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH] configs: stm32mp15: move bootdelay configuration in defconfig
Hi Patrick On 3/1/21 7:40 PM, Patrick Delaunay wrote: > The STM32MP15 boards have no reason to configure bootdelay in stm32mp1.h > as it is already done with CONFIG_BOOTDELAY (default = 2) and in > include/env_default.h. > > This patch allows configuration for customers which reuse stm32mp1.h > and reduce the size of the default environment. > > Signed-off-by: Patrick Delaunay > --- > > configs/stm32mp15_basic_defconfig | 1 + > configs/stm32mp15_dhcom_basic_defconfig | 1 + > configs/stm32mp15_dhcor_basic_defconfig | 1 + > configs/stm32mp15_trusted_defconfig | 1 + > include/configs/stm32mp1.h | 1 - > 5 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/configs/stm32mp15_basic_defconfig > b/configs/stm32mp15_basic_defconfig > index 1c680984b8..0864d4f252 100644 > --- a/configs/stm32mp15_basic_defconfig > +++ b/configs/stm32mp15_basic_defconfig > @@ -20,6 +20,7 @@ CONFIG_SPL_SPI_SUPPORT=y > CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1" > CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > +CONFIG_BOOTDELAY=1 > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > CONFIG_SPL_LOG=y > CONFIG_BOARD_EARLY_INIT_F=y > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index ed285e9161..e36d34d001 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -19,6 +19,7 @@ CONFIG_FIT=y > CONFIG_SPL_LOAD_FIT=y > CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its" > # CONFIG_USE_SPL_FIT_GENERATOR is not set > +CONFIG_BOOTDELAY=1 > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index a6620561ac..4794b1a14d 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -17,6 +17,7 @@ CONFIG_FIT=y > CONFIG_SPL_LOAD_FIT=y > CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its" > # CONFIG_USE_SPL_FIT_GENERATOR is not set > +CONFIG_BOOTDELAY=1 > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y > diff --git a/configs/stm32mp15_trusted_defconfig > b/configs/stm32mp15_trusted_defconfig > index 107041119f..4becdbb238 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -13,6 +13,7 @@ CONFIG_ENV_OFFSET_REDUND=0x2C > CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1" > CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > +CONFIG_BOOTDELAY=1 > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > CONFIG_SYS_PROMPT="STM32MP> " > CONFIG_CMD_ADTIMG=y > diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h > index 36e400453e..db2117a3d7 100644 > --- a/include/configs/stm32mp1.h > +++ b/include/configs/stm32mp1.h > @@ -160,7 +160,6 @@ > * and the ramdisk at the end. > */ > #define CONFIG_EXTRA_ENV_SETTINGS \ > - "bootdelay=1\0" \ > "kernel_addr_r=0xc200\0" \ > "fdt_addr_r=0xc400\0" \ > "scriptaddr=0xc410\0" \ > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [Uboot-stm32] [PATCH 1/2] video: dw_mipi_dsi: missing device to log debug
Hi Patrick On 3/4/21 1:14 PM, Patrick Delaunay wrote: > From: Yannick Fertre > > Missing udevice to struct dw_mipi_dsi to log trace. > > Signed-off-by: Yannick Fertre > Signed-off-by: Patrick Delaunay > --- > > drivers/video/dw_mipi_dsi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c > index 4dde648814..a5beed3514 100644 > --- a/drivers/video/dw_mipi_dsi.c > +++ b/drivers/video/dw_mipi_dsi.c > @@ -797,6 +797,7 @@ static int dw_mipi_dsi_init(struct udevice *dev, > dsi->phy_ops = phy_ops; > dsi->max_data_lanes = max_data_lanes; > dsi->device = device; > + dsi->dsi_host.dev = (struct device *)dev; > dsi->dsi_host.ops = &dw_mipi_dsi_host_ops; > device->host = &dsi->dsi_host; > > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [Uboot-stm32] [PATCH 2/2] video: dw_mipi_dsi: update log of dphy_enable
HI Patrick On 3/4/21 1:14 PM, Patrick Delaunay wrote: > From: Yannick Fertre > > The DSI phy can be turned on from the DSI digital interface in > the dphy_enable() function or from a dedicated DSI phy "wrapper" > in phy_ops->init() function. If the STM32MP1 case, the wrapper > is used then the dphy_enable() "warning" traces are not relevant. > > This patch moves these "warning" traces to "debug" traces so > they are still available for DSI phy based on the digital > interface in debug logging mode, but not there in normal mode > for both cases. > Note: The related Linux kernel driver uses a "debug" > message too. > > Signed-off-by: Yannick Fertre > Signed-off-by: Patrick Delaunay > --- > > drivers/video/dw_mipi_dsi.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c > index a5beed3514..9ae09eec12 100644 > --- a/drivers/video/dw_mipi_dsi.c > +++ b/drivers/video/dw_mipi_dsi.c > @@ -721,15 +721,15 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi > *dsi) > ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val, >val & PHY_LOCK, PHY_STATUS_TIMEOUT_US); > if (ret) > - dev_warn(dsi->dsi_host.dev, > - "failed to wait phy lock state\n"); > + dev_dbg(dsi->dsi_host.dev, > + "failed to wait phy lock state\n"); > > ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, >val, val & PHY_STOP_STATE_CLK_LANE, >PHY_STATUS_TIMEOUT_US); > if (ret) > - dev_warn(dsi->dsi_host.dev, > - "failed to wait phy clk lane stop state\n"); > + dev_dbg(dsi->dsi_host.dev, > + "failed to wait phy clk lane stop state\n"); > } > > static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi) > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH] arm: stm32mp1: Set soc_type, soc_pkg, soc_rev env variables
Hi Marek On 3/5/21 3:18 PM, Marek Vasut wrote: > Split up get_soc_name(), clean the decoding up a bit, and set up > environment variables which contain the SoC type, package, revision. > This is useful on SoMs, where multiple SoC options are populated. > > Signed-off-by: Marek Vasut > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > arch/arm/mach-stm32mp/cpu.c | 105 ++-- > 1 file changed, 53 insertions(+), 52 deletions(-) > > diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c > index 3faa4ec18a4..887db9b5b0c 100644 > --- a/arch/arm/mach-stm32mp/cpu.c > +++ b/arch/arm/mach-stm32mp/cpu.c > @@ -349,89 +349,78 @@ u32 get_cpu_package(void) > return get_otp(BSEC_OTP_PKG, PKG_SHIFT, PKG_MASK); > } > > -void get_soc_name(char name[SOC_NAME_SIZE]) > +static const char * const soc_type[] = { > + "", > + "151C", "151A", "151F", "151D", > + "153C", "153A", "153F", "153D", > + "157C", "157A", "157F", "157D" > +}; > + > +static const char * const soc_pkg[] = { "??", "AD", "AC", "AB", "AA" }; > +static const char * const soc_rev[] = { "?", "A", "B", "Z" }; > + > +static void get_cpu_string_offsets(unsigned int *type, unsigned int *pkg, > +unsigned int *rev) > { > - char *cpu_s, *cpu_r, *pkg; > + u32 cpu_type = get_cpu_type(); > + u32 ct = cpu_type & ~(BIT(7) | BIT(0)); > + u32 cm = ((cpu_type & BIT(7)) >> 6) | (cpu_type & BIT(0)); > + u32 cp = get_cpu_package(); > > - /* MPUs Part Numbers */ > - switch (get_cpu_type()) { > - case CPU_STM32MP157Fxx: > - cpu_s = "157F"; > - break; > - case CPU_STM32MP157Dxx: > - cpu_s = "157D"; > - break; > - case CPU_STM32MP157Cxx: > - cpu_s = "157C"; > - break; > - case CPU_STM32MP157Axx: > - cpu_s = "157A"; > - break; > - case CPU_STM32MP153Fxx: > - cpu_s = "153F"; > - break; > - case CPU_STM32MP153Dxx: > - cpu_s = "153D"; > + /* Bits 0 and 7 are the ACDF, 00:C 01:A 10:F 11:D */ > + switch (ct) { > + case CPU_STM32MP151Cxx: > + *type = cm + 1; > break; > case CPU_STM32MP153Cxx: > - cpu_s = "153C"; > - break; > - case CPU_STM32MP153Axx: > - cpu_s = "153A"; > - break; > - case CPU_STM32MP151Fxx: > - cpu_s = "151F"; > - break; > - case CPU_STM32MP151Dxx: > - cpu_s = "151D"; > + *type = cm + 5; > break; > - case CPU_STM32MP151Cxx: > - cpu_s = "151C"; > - break; > - case CPU_STM32MP151Axx: > - cpu_s = "151A"; > + case CPU_STM32MP157Cxx: > + *type = cm + 9; > break; > default: > - cpu_s = ""; > + *type = 0; > break; > } > > /* Package */ > - switch (get_cpu_package()) { > + switch (cp) { > case PKG_AA_LBGA448: > - pkg = "AA"; > - break; > case PKG_AB_LBGA354: > - pkg = "AB"; > - break; > case PKG_AC_TFBGA361: > - pkg = "AC"; > - break; > case PKG_AD_TFBGA257: > - pkg = "AD"; > + *pkg = cp; > break; > default: > - pkg = "??"; > + pkg = 0; > break; > } > > - /* REVISION */ > + /* Revision */ > switch (get_cpu_rev()) { > case CPU_REVA: > - cpu_r = "A"; > + *rev = 1; > break; > case CPU_REVB: > - cpu_r = "B"; > + *rev = 2; > break; > case CPU_REVZ: > - cpu_r = "Z"; > + *rev = 3; > break; > default: > - cpu_r = "?"; > + *rev = 0; > break; > } > +} > + > +void get_soc_name(char name[SOC_NAME_SIZE]) > +{ > + unsigned int type, pkg, rev; > > - snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s", cpu_s, pkg, cpu_r); > + get_cpu_string_offsets(&type, &pkg, &rev); > + > + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s", > + soc_type[type], soc_pkg[pkg], soc_rev[rev]); > } > > #if defined(CONFIG_DISPLAY_CPUINFO) > @@ -620,11 +609,23 @@ static int setup_serial_number(void) > return 0; > } > > +static void setup_soc_type_pkg_rev(void) > +{ > + unsigned int type, pkg, rev; > + > + get_cpu_string_offsets(&type, &pkg, &rev); > + > + env_set("soc_type", soc_type[type]); > + env_set("soc_pkg", soc_pkg[pkg]); > + env_set("soc_rev", soc_rev[rev]); > +} > + > int arch_misc_init(void) > { > setup_boot_mode(); > setup_mac_address(); > setup_serial_number(); > + setup_soc_type_pkg_rev(); > > return 0; > } > Reviewed-by: Patrice Chotard
Re: [PATCH] doc: stm32mp1: Use u-boot.itb if CONFIG_SPL_LOAD_FIT=y
Hi Marek On 3/6/21 9:44 PM, Marek Vasut wrote: > For systems where SPL loads fitImage, i.e. CONFIG_SPL_LOAD_FIT=y, use > u-boot.itb in the relevant documentation parts. Otherwise use u-boot.img. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > doc/board/st/stm32mp1.rst | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst > index 20f5c9e301e..f0c2b09b988 100644 > --- a/doc/board/st/stm32mp1.rst > +++ b/doc/board/st/stm32mp1.rst > @@ -237,7 +237,8 @@ Build Procedure >- For Basic boot > > - FSBL = spl/u-boot-spl.stm32 > - - SSBL = u-boot.img > + - SSBL = u-boot.img (without CONFIG_SPL_LOAD_FIT) or > + u-boot.itb (with CONFIG_SPL_LOAD_FIT=y) > > Switch Setting for Boot Mode > > @@ -347,7 +348,9 @@ c) copy the FSBL (2 times) and SSBL file on the correct > partition. > > # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1 > # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2 > -# dd if=u-boot.img of=/dev/mmcblk0p3 > +# dd if=u-boot.img of=/dev/mmcblk0p3 # Without CONFIG_SPL_LOAD_FIT > + OR > + dd if=u-boot.itb of=/dev/mmcblk0p3 # With CONFIG_SPL_LOAD_FIT=y > > for trusted boot mode: :: > > @@ -363,8 +366,9 @@ Prepare eMMC > You can use U-Boot to copy binary in eMMC. > > In the next example, you need to boot from SD card and the images > -(u-boot-spl.stm32, u-boot.img) are presents on SD card (mmc 0) > -in ext4 partition 4 (bootfs). > +(u-boot-spl.stm32, u-boot.img for systems without CONFIG_SPL_LOAD_FIT > +or u-boot.itb for systems with CONFIG_SPL_LOAD_FIT=y) are presents on > +SD card (mmc 0) in ext4 partition 4 (bootfs). > > To boot from SD card, select BootPinMode = 1 0 1 and reset. > > @@ -387,7 +391,9 @@ b) copy SPL on eMMC on firts boot partition > > c) copy U-Boot in first GPT partition of eMMC:: > > -# ext4load mmc 0:4 0xC000 u-boo t.img > +# ext4load mmc 0:4 0xC000 u-boot.img # Without CONFIG_SPL_LOAD_FIT > + OR > + ext4load mmc 0:4 0xC000 u-boot.itb # With CONFIG_SPL_LOAD_FIT=y > # mmc dev 1 > # part start mmc 1 1 partstart > # mmc write ${fileaddr} ${partstart} ${filesize} > Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building with LTO, move $(PLATFORM_LIBS) into the --start-group / > --end-group list. This should be --whole-archive > Otherwise some functions declared in assembly may not be resolved and > linking may fail. I am not sure if this is caused by we build these lib functions with -flto? > > Signed-off-by: Marek Behún > --- > Makefile | 3 ++- > scripts/Makefile.spl | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > Regards, Bin
Re: [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building with LTO, the system libc's `errno` variable used in > arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in > lib/errno.c) with the following error: > .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6 > section .tbss mismatches non-TLS reference in > /tmp/u-boot.EQlEXz.ltrans0.ltrans.o > > To avoid this conflict use different asm label for this variable when > CONFIG_SANDBOX is enabled. > > Signed-off-by: Marek Behún > --- > include/errno.h | 8 +++- > lib/errno.c | 4 +++- > 2 files changed, 10 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH] rtc: add support for rv3028 rtc
Hi Heiko, On 09.03.21 14:45, Heiko Schocher wrote: add support for rtc3028 rtc from microcrystal. based on linux dirver: commit a38fd8748464: ("Linux 5.12-rc2") Nitpicking: You might want to start a sentence in upper-case? ;) Another minor comment below... Signed-off-by: Heiko Schocher --- driver is based on code in linux, but with already corrected weekday usage. linux codes the weekday bitwise, while the weekday register has only 3 valid bits as the app manual [1] says: This register holds the current day of the week. Each value represents one weekday that is assigned by the user. Values will range from 0 to 6 The weekday counter is simply a 3-bit counter which counts up to 6 and then resets to 0. [1] https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf This is not a big problem, as userspace never use weekday. Nevertheless, I will also send an update for the linux driver. Also the nvram can be used for bootcounter purposes. Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board. azure build: https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results drivers/rtc/Kconfig | 6 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rv3028.c | 215 +++ 3 files changed, 222 insertions(+) create mode 100644 drivers/rtc/rv3028.c diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index aa6d90158c..e451308b40 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -95,6 +95,12 @@ config RTC_PCF8563 If you say yes here you get support for the Philips PCF8563 RTC and compatible chips. +config RTC_RV3028 + bool "Enable RV3028 driver" + depends on DM_RTC + help + The MicroCrystal RV3028 is a I2C Real Time Clock (RTC) + config RTC_RV3029 bool "Enable RV3029 driver" depends on DM_RTC diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 6a45a9c874..e7acd76266 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o obj-$(CONFIG_RTC_PL031) += pl031.o obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o +obj-$(CONFIG_RTC_RV3028) += rv3028.o obj-$(CONFIG_RTC_RV3029) += rv3029.o obj-$(CONFIG_RTC_RV8803) += rv8803.o obj-$(CONFIG_RTC_RX8025) += rx8025.o diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c new file mode 100644 index 00..8d8336c5f1 --- /dev/null +++ b/drivers/rtc/rv3028.c @@ -0,0 +1,215 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * RTC driver for the Micro Crystal RV3028 + * + * based on linux driver from + * Copyright (C) 2019 Micro Crystal SA + * + * Alexandre Belloni + * + */ + +#include Please don't include "common.h" any more. It's deprecated. +#include Do you really need "command.h" ... +#include +#include ... and this one? Please check and only inlude the necessary headers. Other that that: Reviewed-by: Stefan Roese Thanks, Stefan +#include +#include +#include +#include +#include +#include + +#define RV3028_SEC 0x00 +#define RV3028_MIN 0x01 +#define RV3028_HOUR0x02 +#define RV3028_WDAY0x03 +#define RV3028_DAY 0x04 +#define RV3028_MONTH 0x05 +#define RV3028_YEAR0x06 +#define RV3028_ALARM_MIN 0x07 +#define RV3028_ALARM_HOUR 0x08 +#define RV3028_ALARM_DAY 0x09 +#define RV3028_STATUS 0x0E +#define RV3028_CTRL1 0x0F +#define RV3028_CTRL2 0x10 +#define RV3028_EVT_CTRL0x13 +#define RV3028_TS_COUNT0x14 +#define RV3028_TS_SEC 0x15 +#define RV3028_RAM10x1F +#define RV3028_EEPROM_ADDR 0x25 +#define RV3028_EEPROM_DATA 0x26 +#define RV3028_EEPROM_CMD 0x27 +#define RV3028_CLKOUT 0x35 +#define RV3028_OFFSET 0x36 +#define RV3028_BACKUP 0x37 + +#define RV3028_STATUS_PORF BIT(0) +#define RV3028_STATUS_EVF BIT(1) +#define RV3028_STATUS_AF BIT(2) +#define RV3028_STATUS_TF BIT(3) +#define RV3028_STATUS_UF BIT(4) +#define RV3028_STATUS_BSF BIT(5) +#define RV3028_STATUS_CLKF BIT(6) +#define RV3028_STATUS_EEBUSY BIT(7) + +#define RV3028_CLKOUT_FD_MASK GENMASK(2, 0) +#define RV3028_CLKOUT_PORIEBIT(3) +#define RV3028_CLKOUT_CLKSYBIT(6) +#define RV3028_CLKOUT_CLKOEBIT(7) + +#define RV3028_CTRL1_EERD BIT(3) +#define RV3028_CTRL1_WADA BIT(5) + +#define RV3028_CTRL2_RESET BIT(0) +#define RV3028_CTRL2_12_24 BIT(1) +#define RV3028_CTRL2_EIE BIT(2) +#define RV3028_CTRL2_AIE B
Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog
On 09.03.21 14:27, Pali Rohár wrote: On Tuesday 09 March 2021 12:33:24 Stefan Roese wrote: On 05.03.21 22:36, Pali Rohár wrote: In some cases it is useful to compile support for U-Boot command 'wdt' without starting HW watchdog in early U-Boot phase. For example when user Nitpicking: when "the" user want to start watchdog only on demand by some boot script. This change adds a new compile option WATCHDOG_AUTOSTART to control whether U-Boot should automatically start watchdog during init phase or not. start "the" watchdog This option is enabled by default as it was was default behavior prior as it was the default introducing this new change. When compiling U-Boot users can decide to turn this option off. Signed-off-by: Pali Rohár --- drivers/watchdog/Kconfig | 13 + drivers/watchdog/wdt-uclass.c | 7 +++ 2 files changed, 20 insertions(+) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 602ccbe41c00..aa76a8f2d239 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -9,6 +9,19 @@ config WATCHDOG this option if you want to service enabled watchdog by U-Boot. Disable this option if you want U-Boot to start watchdog but never service it. +config WATCHDOG_AUTOSTART + bool "Automatically start watchdog timer" + depends on WDT + default y + help + Automatically start watchdog timer and start servicing it during + init phase. Enabled by default. Disable this option if you want + to compile U-Boot with CONFIG_WDT support but do not want to + activate watchdog, like when CONFIG_WDT option is disabled. You + would be able to start watchdog manually by 'wdt' command. Useful + when you want to have support for 'wdt' command but do not want + to have watchdog enabled by default. + config WATCHDOG_TIMEOUT_MSECS int "Watchdog timeout in msec" default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6 diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 7500b3ed90e3..00a408bf5cc5 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -27,7 +27,9 @@ static ulong reset_period = 1000; int initr_watchdog(void) { u32 timeout = WATCHDOG_TIMEOUT_SECS; +#ifdef CONFIG_WATCHDOG_AUTOSTART int ret; +#endif Please don't add more #ifdef's if possible, see below... /* * Init watchdog: This will call the probe function of the @@ -51,6 +53,10 @@ int initr_watchdog(void) 4 * reset_period) / 4; } +#ifndef CONFIG_WATCHDOG_AUTOSTART + printf("WDT: Not starting\n"); + return 0; +#else ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); if (ret != 0) { printf("WDT: Failed to start\n"); @@ -61,6 +67,7 @@ int initr_watchdog(void) IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); return 0; +#endif Please use this instead here: if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) { ... Thanks, Stefan } int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) Viele Grüße, Stefan I have fixed these issues in V2. Thanks. Could you please next time when sending an updated patch series / version include the tags, like my RB tag? As patchwork collects these automatically and now I need to re-send them again - which I will do this time. ;) Thanks, Stefan
Re: [PATCH v2 1/4] watchdog: Set/unset GD_FLG_WDT_READY flag in wdt_start()/wdt_stop()
On 09.03.21 14:26, Pali Rohár wrote: Watchdog is ready after successful call of ops->start() callback in wdt_start() function. And is stopped after successful call of ops->stop() callback in wdt_stop function. So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop() function. This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is running. And ensures that flag is also also when watchdog was started not only by initr_watchdog() call (e.g. by U-Boot 'wdt' command). Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/watchdog/wdt-uclass.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 28f7918c4673..3f707f61f74f 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -51,7 +51,6 @@ int initr_watchdog(void) } wdt_start(gd->watchdog_dev, timeout * 1000, 0); - gd->flags |= GD_FLG_WDT_READY; printf("WDT: Started with%s servicing (%ds timeout)\n", IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); @@ -61,21 +60,31 @@ int initr_watchdog(void) int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) { const struct wdt_ops *ops = device_get_ops(dev); + int ret; if (!ops->start) return -ENOSYS; - return ops->start(dev, timeout_ms, flags); + ret = ops->start(dev, timeout_ms, flags); + if (ret == 0) + gd->flags |= GD_FLG_WDT_READY; + + return ret; } int wdt_stop(struct udevice *dev) { const struct wdt_ops *ops = device_get_ops(dev); + int ret; if (!ops->stop) return -ENOSYS; - return ops->stop(dev); + ret = ops->stop(dev); + if (ret == 0) + gd->flags &= ~GD_FLG_WDT_READY; + + return ret; } int wdt_reset(struct udevice *dev) Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 2/4] watchdog: Show error message when initr_watchdog() cannot start watchdog
On 09.03.21 14:26, Pali Rohár wrote: Function wdt_start() may fail. So in initr_watchdog() function check return value of wdt_start() call and print error message when watchdog starting failed. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/watchdog/wdt-uclass.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 3f707f61f74f..7500b3ed90e3 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -27,6 +27,7 @@ static ulong reset_period = 1000; int initr_watchdog(void) { u32 timeout = WATCHDOG_TIMEOUT_SECS; + int ret; /* * Init watchdog: This will call the probe function of the @@ -50,7 +51,12 @@ int initr_watchdog(void) 4 * reset_period) / 4; } - wdt_start(gd->watchdog_dev, timeout * 1000, 0); + ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); + if (ret != 0) { + printf("WDT: Failed to start\n"); + return 0; + } + printf("WDT: Started with%s servicing (%ds timeout)\n", IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog
On 09.03.21 14:26, Pali Rohár wrote: In some cases it is useful to compile support for U-Boot command 'wdt' without starting HW watchdog in early U-Boot phase. For example when the user want to start the watchdog only on demand by some boot script. This change adds a new compile option WATCHDOG_AUTOSTART to control whether U-Boot should automatically start the watchdog during init phase or not. This option is enabled by default as it was the default behavior prior introducing this new change. When compiling U-Boot users can decide to turn this option off. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/watchdog/Kconfig | 13 + drivers/watchdog/wdt-uclass.c | 5 + 2 files changed, 18 insertions(+) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 602ccbe41c00..aa76a8f2d239 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -9,6 +9,19 @@ config WATCHDOG this option if you want to service enabled watchdog by U-Boot. Disable this option if you want U-Boot to start watchdog but never service it. +config WATCHDOG_AUTOSTART + bool "Automatically start watchdog timer" + depends on WDT + default y + help + Automatically start watchdog timer and start servicing it during + init phase. Enabled by default. Disable this option if you want + to compile U-Boot with CONFIG_WDT support but do not want to + activate watchdog, like when CONFIG_WDT option is disabled. You + would be able to start watchdog manually by 'wdt' command. Useful + when you want to have support for 'wdt' command but do not want + to have watchdog enabled by default. + config WATCHDOG_TIMEOUT_MSECS int "Watchdog timeout in msec" default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6 diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c index 7500b3ed90e3..0603ffbd36d9 100644 --- a/drivers/watchdog/wdt-uclass.c +++ b/drivers/watchdog/wdt-uclass.c @@ -51,6 +51,11 @@ int initr_watchdog(void) 4 * reset_period) / 4; } + if (!CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) { + printf("WDT: Not starting\n"); + return 0; + } + ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); if (ret != 0) { printf("WDT: Failed to start\n"); Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 4/4] arm: mvebu: Espressobin: Enable watchdog support but do not start it
On 09.03.21 14:26, Pali Rohár wrote: Espressobin had disabled watchdog support (CONFIG_WDT) because older stable Linux kernel versions (which are used by current stable OpenWRT and Debian versions) do not have support for Armada 3700 watchdog driver. Therefore they are not able to periodically kick watchdog so Espressobin enter into boot loop. This change enable CONFIG_WDT, CONFIG_WDT_ARMADA_37XX and CONFIG_CMD_WDT options which add support for U-Boot 'wdt' command. And unset new CONFIG_WATCHDOG_AUTOSTART option which cause that watchdog is not automatically started by U-Boot during init phase, like when CONFIG_WDT option is not set at all. So with this change, U-Boot on Espressobin would have working 'wdt' command which can be used from boot scripts (e.g. for enabling watchdog prior new Linux booting kernel). But default behavior of watchdog status stays unchanged, U-Boot does not start watchdog on Espressobin during its init phase. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- configs/mvebu_espressobin-88f3720_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index c791f98dfea5..20aa21b06b3d 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -32,6 +32,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y @@ -88,5 +89,8 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ARMADA_37XX=y CONFIG_SHA1=y CONFIG_SHA256=y Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog
On Tuesday 09 March 2021 17:12:40 Stefan Roese wrote: > On 09.03.21 14:27, Pali Rohár wrote: > > On Tuesday 09 March 2021 12:33:24 Stefan Roese wrote: > > > On 05.03.21 22:36, Pali Rohár wrote: > > > > In some cases it is useful to compile support for U-Boot command 'wdt' > > > > without starting HW watchdog in early U-Boot phase. For example when > > > > user > > > > > > Nitpicking: > > >when "the" user > > > > > > > want to start watchdog only on demand by some boot script. > > > > > > > > This change adds a new compile option WATCHDOG_AUTOSTART to control > > > > whether > > > > U-Boot should automatically start watchdog during init phase or not. > > > > > >start "the" watchdog > > > > > > > > > > > This option is enabled by default as it was was default behavior prior > > > > > >as it was the default > > > > > > > introducing this new change. When compiling U-Boot users can decide to > > > > turn > > > > this option off. > > > > > > > > Signed-off-by: Pali Rohár > > > > --- > > > >drivers/watchdog/Kconfig | 13 + > > > >drivers/watchdog/wdt-uclass.c | 7 +++ > > > >2 files changed, 20 insertions(+) > > > > > > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > > > > index 602ccbe41c00..aa76a8f2d239 100644 > > > > --- a/drivers/watchdog/Kconfig > > > > +++ b/drivers/watchdog/Kconfig > > > > @@ -9,6 +9,19 @@ config WATCHDOG > > > > this option if you want to service enabled watchdog by > > > > U-Boot. Disable > > > > this option if you want U-Boot to start watchdog but never > > > > service it. > > > > +config WATCHDOG_AUTOSTART > > > > + bool "Automatically start watchdog timer" > > > > + depends on WDT > > > > + default y > > > > + help > > > > + Automatically start watchdog timer and start servicing it > > > > during > > > > + init phase. Enabled by default. Disable this option if you > > > > want > > > > + to compile U-Boot with CONFIG_WDT support but do not want to > > > > + activate watchdog, like when CONFIG_WDT option is disabled. > > > > You > > > > + would be able to start watchdog manually by 'wdt' command. > > > > Useful > > > > + when you want to have support for 'wdt' command but do not > > > > want > > > > + to have watchdog enabled by default. > > > > + > > > >config WATCHDOG_TIMEOUT_MSECS > > > > int "Watchdog timeout in msec" > > > > default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6 > > > > diff --git a/drivers/watchdog/wdt-uclass.c > > > > b/drivers/watchdog/wdt-uclass.c > > > > index 7500b3ed90e3..00a408bf5cc5 100644 > > > > --- a/drivers/watchdog/wdt-uclass.c > > > > +++ b/drivers/watchdog/wdt-uclass.c > > > > @@ -27,7 +27,9 @@ static ulong reset_period = 1000; > > > >int initr_watchdog(void) > > > >{ > > > > u32 timeout = WATCHDOG_TIMEOUT_SECS; > > > > +#ifdef CONFIG_WATCHDOG_AUTOSTART > > > > int ret; > > > > +#endif > > > > > > Please don't add more #ifdef's if possible, see below... > > > > > > > /* > > > > * Init watchdog: This will call the probe function of the > > > > @@ -51,6 +53,10 @@ int initr_watchdog(void) > > > > 4 * reset_period) / > > > > 4; > > > > } > > > > +#ifndef CONFIG_WATCHDOG_AUTOSTART > > > > + printf("WDT: Not starting\n"); > > > > + return 0; > > > > +#else > > > > ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0); > > > > if (ret != 0) { > > > > printf("WDT: Failed to start\n"); > > > > @@ -61,6 +67,7 @@ int initr_watchdog(void) > > > >IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout); > > > > return 0; > > > > +#endif > > > > > > Please use this instead here: > > > > > > if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) { > > > ... > > > > > > Thanks, > > > Stefan > > > > > > >} > > > >int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) > > > > > > > > > > > > > Viele Grüße, > > > Stefan > > > > I have fixed these issues in V2. > > Thanks. > > Could you please next time when sending an updated patch series / > version include the tags, like my RB tag? As patchwork collects > these automatically and now I need to re-send them again - which I > will do this time. ;) > > Thanks, > Stefan Ok, no problem!
Re: [PATCH] rtc: add support for rv3028 rtc
On 09/03/2021 17:10:21+0100, Stefan Roese wrote: > Hi Heiko, > > On 09.03.21 14:45, Heiko Schocher wrote: > > add support for rtc3028 rtc from microcrystal. > > based on linux dirver: > > commit a38fd8748464: ("Linux 5.12-rc2") > > Nitpicking: You might want to start a sentence in upper-case? ;) > > Another minor comment below... > > > Signed-off-by: Heiko Schocher > > > > --- > > driver is based on code in linux, but with already > > corrected weekday usage. linux codes the weekday > > bitwise, while the weekday register has only 3 valid > > bits as the app manual [1] says: > > > > This register holds the current day of the week. Each value represents > > one weekday that is assigned by the user. Values will range from 0 to 6 > > The weekday counter is simply a 3-bit counter which counts up to 6 > > and then resets to 0. > > > > [1] > > https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf > > > > This is not a big problem, as userspace never use weekday. > > Nevertheless, I will also send an update for the linux driver. > > > > Also the nvram can be used for bootcounter purposes. > > > > Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board. > > > > azure build: > > https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results > > > > drivers/rtc/Kconfig | 6 ++ > > drivers/rtc/Makefile | 1 + > > drivers/rtc/rv3028.c | 215 +++ > > 3 files changed, 222 insertions(+) > > create mode 100644 drivers/rtc/rv3028.c > > > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > > index aa6d90158c..e451308b40 100644 > > --- a/drivers/rtc/Kconfig > > +++ b/drivers/rtc/Kconfig > > @@ -95,6 +95,12 @@ config RTC_PCF8563 > > If you say yes here you get support for the Philips PCF8563 RTC > > and compatible chips. > > +config RTC_RV3028 > > + bool "Enable RV3028 driver" > > + depends on DM_RTC > > + help > > + The MicroCrystal RV3028 is a I2C Real Time Clock (RTC) > > + > > config RTC_RV3029 > > bool "Enable RV3029 driver" > > depends on DM_RTC > > diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile > > index 6a45a9c874..e7acd76266 100644 > > --- a/drivers/rtc/Makefile > > +++ b/drivers/rtc/Makefile > > @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o > > obj-$(CONFIG_RTC_PL031) += pl031.o > > obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o > > obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o > > +obj-$(CONFIG_RTC_RV3028) += rv3028.o > > obj-$(CONFIG_RTC_RV3029) += rv3029.o > > obj-$(CONFIG_RTC_RV8803) += rv8803.o > > obj-$(CONFIG_RTC_RX8025) += rx8025.o > > diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c > > new file mode 100644 > > index 00..8d8336c5f1 > > --- /dev/null > > +++ b/drivers/rtc/rv3028.c > > @@ -0,0 +1,215 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * RTC driver for the Micro Crystal RV3028 > > + * > > + * based on linux driver from > > + * Copyright (C) 2019 Micro Crystal SA > > + * > > + * Alexandre Belloni > > + * > > + */ > > + > > +#include > > Please don't include "common.h" any more. It's deprecated. > > > +#include > > Do you really need "command.h" ... > > > +#include > > +#include > > ... and this one? Please check and only inlude the necessary headers. > Wouldn't that be needed to expose the on board NVRAM or EEPROM? However I don't see any code to access that right now. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH] disk: gpt: verify alternate LBA points to last usable LBA
Hi Heinrich, Am 08.03.2021 um 18:38 schrieb Heinrich Schuchardt: On 08.03.21 17:07, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier The gpt command require the GPT backup header at the standard location at the end of the device.Check the alternate LBA value before reading the GPT backup header from the last usable LBA of the device. If there is a bug in the gpt command, please, fix it instead of introducing constraints that don't exist in the UEFI specification. The UEFI specification has: "The backup GPT Partition Entry Array must be located after the Last Usable LBA and end before the backup GPT Header." "If the primary GPT is invalid, the backup GPT is used instead and it is located on the last logical block on the disk." [UEFI specification 2.8, S. 120] "Note that UEFI standard requires the backup header at the end of the device and partitioning tools can automatically relocate the header to follow the standard." [sfdisk man page, --relocate, gpt-bak-mini] What should U-Boot do? I have a patch to use the backup GPT header if only the header itself is valid but I don't know if this behavior is correct. Regards, Stefan
Re: [PATCH] disk: gpt: verify alternate LBA points to last usable LBA
On 09.03.21 17:24, Stefan Herbrechtsmeier wrote: > Hi Heinrich, > > Am 08.03.2021 um 18:38 schrieb Heinrich Schuchardt: >> On 08.03.21 17:07, Stefan Herbrechtsmeier wrote: >>> From: Stefan Herbrechtsmeier >>> >>> The gpt command require the GPT backup header at the standard location >>> at the end of the device.Check the alternate LBA value before reading >>> the GPT backup header from the last usable LBA of the device. >> >> If there is a bug in the gpt command, please, fix it instead of >> introducing constraints that don't exist in the UEFI specification. >> >> The UEFI specification has: >> >> "The backup GPT Partition Entry Array must be located after the Last >> Usable LBA and end before the backup GPT Header." > > "If the primary GPT is invalid, the backup GPT is used instead and it is > located on the last logical block on the disk." [UEFI specification 2.8, > S. 120] Thank you for pointing me to this sentence which I missed. Reviewed-by: Heinrich Schuchardt > > "Note that UEFI standard requires the backup header at the end of the > device and partitioning tools can automatically relocate the header to > follow the standard." [sfdisk man page, --relocate, gpt-bak-mini] > > What should U-Boot do? I have a patch to use the backup GPT header if > only the header itself is valid but I don't know if this behavior is > correct. > > Regards, > Stefan
[PATCH 2/2] configs: am65x_evm_r5: Enable checks for spl and stack sizes
Enable relevant configs that checks for the size of image and stack: BSS: 3KB Initial MALLOC: ~22KB Initial Stack: 8K SPL Image size can be: ~215KB Signed-off-by: Lokesh Vutla --- configs/am65x_evm_r5_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index b9b11010a1..57f3300380 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -17,6 +17,8 @@ CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_SPL_STACK_R_ADDR=0x8200 +CONFIG_SPL_SIZE_LIMIT=0x7ec00 +CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x2000 CONFIG_SPL_FS_FAT=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_SPL_SPI_FLASH_SUPPORT=y @@ -27,6 +29,9 @@ CONFIG_SPL_LOAD_FIT=y # CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_USE_BOOTCOMMAND=y # CONFIG_DISPLAY_CPUINFO is not set +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y +CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_EARLY_BSS=y -- 2.30.0
[PATCH 1/2] include: configs: am65x_evm: Optimize size of SPL BSS
Current BSS allocation of SPL is as below: $ size spl/u-boot-spl textdata bss dec hex filename 13236978521496 141717 22995 spl/u-boot-spl But 20KB is allocated currently for BSS. Reduce it to 3KB and save some space for stack. Signed-off-by: Lokesh Vutla --- include/configs/am65x_evm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h index b39a5b4ca4..76d73086fb 100644 --- a/include/configs/am65x_evm.h +++ b/include/configs/am65x_evm.h @@ -30,7 +30,7 @@ * our memory footprint. The less we use for BSS the more we have available * for everything else. */ -#define CONFIG_SPL_BSS_MAX_SIZE0x5000 +#define CONFIG_SPL_BSS_MAX_SIZE0xc00 /* * Link BSS to be within SPL in a dedicated region located near the top of * the MCU SRAM, this way making it available also before relocation. Note -- 2.30.0
[PATCH v2] Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning
Also convert CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG. Signed-off-by: Pali Rohár --- This patch increase u-boot.bin binary size above maximal limit. So this patch cannot be applied yet. But it can be applied on top of the LTO patches. So please put this patch into the queue and include it into U-Boot after LTO patches are merged. Changes in v2: * converted CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG --- board/nokia/rx51/rx51.c | 37 configs/nokia_rx51_defconfig | 2 ++ include/configs/nokia_rx51.h | 3 --- 3 files changed, 35 insertions(+), 7 deletions(-) diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c index 7bd5fbd71520..fd3cec8358aa 100644 --- a/board/nokia/rx51/rx51.c +++ b/board/nokia/rx51/rx51.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -487,20 +488,20 @@ static unsigned long int twl_wd_time; /* last time of watchdog reset */ static unsigned long int twl_i2c_lock; /* - * Routine: hw_watchdog_reset + * Routine: rx51_watchdog_reset * Description: Reset timeout of twl4030 watchdog. */ -void hw_watchdog_reset(void) +static int rx51_watchdog_reset(struct udevice *dev) { u8 timeout = 0; /* do not reset watchdog too often - max every 4s */ if (get_timer(twl_wd_time) < 4 * CONFIG_SYS_HZ) - return; + return 0; /* localy lock twl4030 i2c bus */ if (test_and_set_bit(0, &twl_i2c_lock)) - return; + return 0; /* read actual watchdog timeout */ twl4030_i2c_read_u8(TWL4030_CHIP_PM_RECEIVER, @@ -517,8 +518,32 @@ void hw_watchdog_reset(void) /* localy unlock twl4030 i2c bus */ test_and_clear_bit(0, &twl_i2c_lock); + + return 0; +} + +static int rx51_watchdog_start(struct udevice *dev, u64 timeout_ms, ulong flags) +{ + return 0; } +static int rx51_watchdog_probe(struct udevice *dev) +{ + return 0; +} + +static const struct wdt_ops rx51_watchdog_ops = { + .start = rx51_watchdog_start, + .reset = rx51_watchdog_reset, +}; + +U_BOOT_DRIVER(rx51_watchdog) = { + .name = "rx51_watchdog", + .id = UCLASS_WDT, + .ops = &rx51_watchdog_ops, + .probe = rx51_watchdog_probe, +}; + /* * TWL4030 keypad handler for cfb_console */ @@ -722,3 +747,7 @@ U_BOOT_DRVINFOS(rx51_i2c) = { { "i2c_omap", &rx51_i2c[1] }, { "i2c_omap", &rx51_i2c[2] }, }; + +U_BOOT_DRVINFOS(rx51_watchdog) = { + { "rx51_watchdog" }, +}; diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig index 312ca3a1a991..80b18e435105 100644 --- a/configs/nokia_rx51_defconfig +++ b/configs/nokia_rx51_defconfig @@ -67,4 +67,6 @@ CONFIG_CFB_CONSOLE=y CONFIG_CFB_CONSOLE_ANSI=y # CONFIG_VGA_AS_SINGLE_DEVICE is not set CONFIG_SPLASH_SCREEN=y +CONFIG_WATCHDOG_TIMEOUT_MSECS=31000 +CONFIG_WDT=y # CONFIG_GZIP is not set diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h index 23368de624e1..fe991ea03991 100644 --- a/include/configs/nokia_rx51.h +++ b/include/configs/nokia_rx51.h @@ -85,9 +85,6 @@ #define CONFIG_SYS_ONENAND_BASEONENAND_MAP -/* Watchdog support */ -#define CONFIG_HW_WATCHDOG - /* * Framebuffer */ -- 2.20.1
[PATCH] cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions
This allows using dev#partlabel syntax. Signed-off-by: Sean Anderson --- fs/fs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fs.c b/fs/fs.c index 900928c394..b7936fd4cf 100644 --- a/fs/fs.c +++ b/fs/fs.c @@ -385,8 +385,8 @@ int fs_set_blk_dev(const char *ifname, const char *dev_part_str, int fstype) } #endif - part = blk_get_device_part_str(ifname, dev_part_str, &fs_dev_desc, - &fs_partition, 1); + part = part_get_info_by_dev_and_name_or_num(ifname, dev_part_str, &fs_dev_desc, + &fs_partition, 1); if (part < 0) return -1; -- 2.25.1
Re: [PATCH] cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions
Am 9. März 2021 21:56:24 MEZ schrieb Sean Anderson : >This allows using dev#partlabel syntax. Allowing more widespread use of that syntax makes sense to me. Unfortunately you do not mention which commands and devices are affected. > >Signed-off-by: Sean Anderson >--- > > fs/fs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/fs/fs.c b/fs/fs.c >index 900928c394..b7936fd4cf 100644 >--- a/fs/fs.c >+++ b/fs/fs.c >@@ -385,8 +385,8 @@ int fs_set_blk_dev(const char *ifname, const char >*dev_part_str, int fstype) > } > #endif > >- part = blk_get_device_part_str(ifname, dev_part_str, &fs_dev_desc, >- &fs_partition, 1); >+ part = part_get_info_by_dev_and_name_or_num(ifname, dev_part_str, >&fs_dev_desc, >+ &fs_partition, 1); > if (part < 0) > return -1; > It would be good if we could test the new capabilities. Can we make use of sandbox_mmc.c? Best regards Heinrich
Re: [PATCH] cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions
On 3/9/21 4:21 PM, Heinrich Schuchardt wrote: > Am 9. März 2021 21:56:24 MEZ schrieb Sean Anderson : >> This allows using dev#partlabel syntax. > > Allowing more widespread use of that syntax makes sense to me. > > Unfortunately you do not mention which commands and devices are affected. I enabled it so that cmd/fs.c can use it (e.g. CMD_FS_GENERIC). It seems like I overlooked that this was in fs/fs.c and not cmd/fs.c. Affected functionality should be most filesystem commands (due to do_load), DFU, fastboot, and splash screen. I suspect this affects almost every device using U-Boot. > >> >> Signed-off-by: Sean Anderson >> --- >> >> fs/fs.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/fs/fs.c b/fs/fs.c >> index 900928c394..b7936fd4cf 100644 >> --- a/fs/fs.c >> +++ b/fs/fs.c >> @@ -385,8 +385,8 @@ int fs_set_blk_dev(const char *ifname, const char >> *dev_part_str, int fstype) >>} >> #endif >> >> - part = blk_get_device_part_str(ifname, dev_part_str, &fs_dev_desc, >> - &fs_partition, 1); >> + part = part_get_info_by_dev_and_name_or_num(ifname, dev_part_str, >> &fs_dev_desc, >> + &fs_partition, 1); >>if (part < 0) >>return -1; >> > > It would be good if we could test the new capabilities. Can we make use of sandbox_mmc.c? I suppose. There are already some tests in test/dm/fastboot.c along these lines. Fastboot calls into part_get_info_by_dev_and_name_or_num, so I think that is testing the same sort of thing. Perhaps they should be broken out into general partition tests. IMO this code path already has adequate tests. --Sean
Re: [PATCH v4 1/5] firmware: scmi: voltage regulator
On 3/9/21 6:38 AM, Etienne Carriere wrote: > Implement voltage regulators interfaced by the SCMI voltage domain > protocol. The DT bindings are defined in the Linux kernel since > SCMI voltage domain and regulators patches [1] and [2] integration > in v5.11-rc7. > > Link: [1] > https://protect2.fireeye.com/v1/url?k=4762535a-18f96b93-4763d815-0cc47a336fae-3c00cacbc555f86e&q=1&e=d232145a-df26-46c6-b2ed-fd2b665c4b71&u=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F0f80fcec08e9c50b8d2992cf26495673765ebaba > Link: [2] > https://protect2.fireeye.com/v1/url?k=3da6e589-623ddd40-3da76ec6-0cc47a336fae-8f68d44282000af5&q=1&e=d232145a-df26-46c6-b2ed-fd2b665c4b71&u=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F2add5cacff3531e54c50b0832128299faa9f0563 > Signed-off-by: Etienne Carriere Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > Changes in v4: > - define a device for SCMI voltage protocol that binds the SCMI regulators > as suggested by Patrick. > - removed Simon and Jaehoon tags since changes. > > Changes in v3: > - applied review tags > > Changes in v2: > - no change > --- > doc/device-tree-bindings/arm/arm,scmi.txt | 34 > drivers/firmware/scmi/scmi_agent-uclass.c | 10 ++ > drivers/power/regulator/Kconfig | 8 + > drivers/power/regulator/Makefile | 1 + > drivers/power/regulator/scmi_regulator.c | 195 ++ > include/scmi_protocols.h | 113 + > 6 files changed, 361 insertions(+) > create mode 100644 drivers/power/regulator/scmi_regulator.c > > diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt > b/doc/device-tree-bindings/arm/arm,scmi.txt > index 1f293ea24..a76124f4a 100644 > --- a/doc/device-tree-bindings/arm/arm,scmi.txt > +++ b/doc/device-tree-bindings/arm/arm,scmi.txt > @@ -62,6 +62,20 @@ Required properties: > - #power-domain-cells : Should be 1. Contains the device or the power >domain ID value used by SCMI commands. > > +Regulator bindings for the SCMI Regulator based on SCMI Message Protocol > + > +An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain, > +and should be always positioned as a root regulator. > +It does not support any current operation. > + > +SCMI Regulators are grouped under a 'regulators' node which in turn is a > child > +of the SCMI Voltage protocol node inside the desired SCMI instance node. > + > +This binding uses the common regulator binding[6]. > + > +Required properties: > + - reg : shall identify an existent SCMI Voltage Domain. > + > Sensor bindings for the sensors based on SCMI Message Protocol > -- > SCMI provides an API to access the various sensors on the SoC. > @@ -105,6 +119,7 @@ Required sub-node properties: > [3] Documentation/devicetree/bindings/thermal/thermal.txt > [4] Documentation/devicetree/bindings/sram/sram.yaml > [5] Documentation/devicetree/bindings/reset/reset.txt > +[6] Documentation/devicetree/bindings/regulator/regulator.yaml > > Example: > > @@ -169,6 +184,25 @@ firmware { > reg = <0x16>; > #reset-cells = <1>; > }; > + > + scmi_voltage: protocol@17 { > + reg = <0x17>; > + > + regulators { > + regulator_devX: regulator@0 { > + reg = <0x0>; > + regulator-max-microvolt = <330>; > + }; > + > + regulator_devY: regulator@9 { > + reg = <0x9>; > + regulator-min-microvolt = <50>; > + regulator-max-microvolt = <420>; > + }; > + > + ... > + }; > + }; > }; > }; > > diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c > b/drivers/firmware/scmi/scmi_agent-uclass.c > index 516e690ac..f13e46c36 100644 > --- a/drivers/firmware/scmi/scmi_agent-uclass.c > +++ b/drivers/firmware/scmi/scmi_agent-uclass.c > @@ -79,6 +79,16 @@ static int scmi_bind_protocols(struct udevice *dev) > if (IS_ENABLED(CONFIG_RESET_SCMI)) > drv = DM_DRIVER_GET(scmi_reset_domain); > break; > + case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN: > + if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI)) { > + node = ofnode_find_subnode(node, "regulators"); > + if (!ofnode_valid(node)) { > + dev_err(dev, "no regulators node\n"); > + return -ENXIO; > + } > + drv =
[PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing
This change adds a callback for preprocessing the FIT header before it is parsed. There are 3 main reasons for this callback: (1) If a vulnerability is discovered in the FIT parsing/loading code, or libfdt, this callback allows users to scan the FIT header for specific exploit signatures and prevent flashing/booting of the image (2) If users want to implement a single signature which covers the entire FIT header, which is then appended to the end of the header, then this callback can be used to authenticate that signature. (3) If users want to check the FIT header contents against specific metadata stored outside the FIT header, then this callback allows them to do that. Signed-off-by: Farhan Ali Cc: Simon Glass Cc: Alexandru Gagniuc Cc: Marek Vasut Cc: Michal Simek Cc: Philippe Reynes Cc: Samuel Holland --- Changes for v2: - Callback now returns a value - Added a log message on failure --- common/spl/spl_fit.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index 75c8ff0..01aee1c 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -43,6 +43,14 @@ __weak ulong board_spl_fit_size_align(ulong size) return size; } +__weak int board_spl_fit_pre_load(struct spl_load_info *load_info, + const void *fit, + ulong start_sector, + ulong loaded_sector_count) +{ + return 0; +} + static int find_node_from_desc(const void *fit, int node, const char *str) { int child; @@ -527,6 +535,7 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx, unsigned long count, size; int sectors; void *buf; + int rc = 0; /* * For FIT with external data, figure out where the external images @@ -552,7 +561,18 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx, debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, size=0x%lx\n", sector, sectors, buf, count, size); - return (count == 0) ? -EIO : 0; + if (count) { + /* preprocess loaded fit header before parsing and loading binaries */ + rc = board_spl_fit_pre_load(info, fit_header, sector, sectors); + if (rc) { + debug("%s: fit header pre processing failed. rc=%d\n", + __func__, rc); + } + } else { + rc = -EIO; + } + + return rc; } static int spl_simple_fit_parse(struct spl_fit_info *ctx) -- 1.8.3.1
Re: [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building with LTO, using -ffunction-sections/-fdata-sections is not > useful anymore. > > Signed-off-by: Marek Behún > --- > arch/arm/config.mk | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > I believe we should also remove --gc-sections. Regards, Bin
Re: Please pull u-boot-x86
On Tue, Mar 09, 2021 at 01:15:22PM +0800, Bin Meng wrote: > Hi Tom, > > This PR includes the following x86 changes for v2021.04: > > - Various minor fixes for x86 > > Azure results: PASS > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=337&view=results > > The following changes since commit 472c5484bca41a477f8b86a263e559f6e992c7f8: > > Merge tag 'u-boot-amlogic-20210308' of > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2021-03-08 > 07:41:50 -0500) > > are available in the git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-x86 > > for you to fetch changes up to 736ecc643de4b329e2edcb3207edd58bf7ed0d9d: > > x86: Select advanced Intel code only if allowed (2021-03-09 09:42:12 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] rtc: add support for rv3028 rtc
Hi stefan, On 09.03.21 17:10, Stefan Roese wrote: > Hi Heiko, > > On 09.03.21 14:45, Heiko Schocher wrote: >> add support for rtc3028 rtc from microcrystal. >> based on linux dirver: >> commit a38fd8748464: ("Linux 5.12-rc2") > > Nitpicking: You might want to start a sentence in upper-case? ;) Yup. > > Another minor comment below... > >> Signed-off-by: Heiko Schocher >> >> --- >> driver is based on code in linux, but with already >> corrected weekday usage. linux codes the weekday >> bitwise, while the weekday register has only 3 valid >> bits as the app manual [1] says: >> >> This register holds the current day of the week. Each value represents >> one weekday that is assigned by the user. Values will range from 0 to 6 >> The weekday counter is simply a 3-bit counter which counts up to 6 >> and then resets to 0. >> >> [1] >> https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf >> >> This is not a big problem, as userspace never use weekday. >> Nevertheless, I will also send an update for the linux driver. >> >> Also the nvram can be used for bootcounter purposes. >> >> Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board. >> >> azure build: >> https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results >> >> drivers/rtc/Kconfig | 6 ++ >> drivers/rtc/Makefile | 1 + >> drivers/rtc/rv3028.c | 215 +++ >> 3 files changed, 222 insertions(+) >> create mode 100644 drivers/rtc/rv3028.c >> >> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig >> index aa6d90158c..e451308b40 100644 >> --- a/drivers/rtc/Kconfig >> +++ b/drivers/rtc/Kconfig >> @@ -95,6 +95,12 @@ config RTC_PCF8563 >> If you say yes here you get support for the Philips PCF8563 RTC >> and compatible chips. >> +config RTC_RV3028 >> + bool "Enable RV3028 driver" >> + depends on DM_RTC >> + help >> + The MicroCrystal RV3028 is a I2C Real Time Clock (RTC) >> + >> config RTC_RV3029 >> bool "Enable RV3029 driver" >> depends on DM_RTC >> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile >> index 6a45a9c874..e7acd76266 100644 >> --- a/drivers/rtc/Makefile >> +++ b/drivers/rtc/Makefile >> @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o >> obj-$(CONFIG_RTC_PL031) += pl031.o >> obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o >> obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o >> +obj-$(CONFIG_RTC_RV3028) += rv3028.o >> obj-$(CONFIG_RTC_RV3029) += rv3029.o >> obj-$(CONFIG_RTC_RV8803) += rv8803.o >> obj-$(CONFIG_RTC_RX8025) += rx8025.o >> diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c >> new file mode 100644 >> index 00..8d8336c5f1 >> --- /dev/null >> +++ b/drivers/rtc/rv3028.c >> @@ -0,0 +1,215 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * RTC driver for the Micro Crystal RV3028 >> + * >> + * based on linux driver from >> + * Copyright (C) 2019 Micro Crystal SA >> + * >> + * Alexandre Belloni >> + * >> + */ >> + >> +#include > > Please don't include "common.h" any more. It's deprecated. > >> +#include > > Do you really need "command.h" ... > >> +#include >> +#include > > ... and this one? Please check and only inlude the necessary headers. Of course, will check them, thanks! > Other that that: > > Reviewed-by: Stefan Roese bye, Heiko > > Thanks, > Stefan > >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define RV3028_SEC 0x00 >> +#define RV3028_MIN 0x01 >> +#define RV3028_HOUR 0x02 >> +#define RV3028_WDAY 0x03 >> +#define RV3028_DAY 0x04 >> +#define RV3028_MONTH 0x05 >> +#define RV3028_YEAR 0x06 >> +#define RV3028_ALARM_MIN 0x07 >> +#define RV3028_ALARM_HOUR 0x08 >> +#define RV3028_ALARM_DAY 0x09 >> +#define RV3028_STATUS 0x0E >> +#define RV3028_CTRL1 0x0F >> +#define RV3028_CTRL2 0x10 >> +#define RV3028_EVT_CTRL 0x13 >> +#define RV3028_TS_COUNT 0x14 >> +#define RV3028_TS_SEC 0x15 >> +#define RV3028_RAM1 0x1F >> +#define RV3028_EEPROM_ADDR 0x25 >> +#define RV3028_EEPROM_DATA 0x26 >> +#define RV3028_EEPROM_CMD 0x27 >> +#define RV3028_CLKOUT 0x35 >> +#define RV3028_OFFSET 0x36 >> +#define RV3028_BACKUP 0x37 >> + >> +#define RV3028_STATUS_PORF BIT(0) >> +#define RV3028_STATUS_EVF BIT(1) >> +#define RV3028_STATUS_AF BIT(2) >> +#define RV3028_STATUS_TF BIT(3) >> +#define RV3028_STATUS_UF BIT(4) >> +#define RV3028_STATUS_BSF BIT(5) >> +#define RV3028_STATUS_CLKF BIT(6) >> +#define RV3028_STATUS_EEBUSY BIT(7) >> + >> +#define RV3028_CLKOUT_FD_MASK GENMASK(2, 0) >> +#define RV3028_CLKOUT_PORIE BIT(3) >> +#define RV3028_CLKOUT_CLKSY BIT(6) >> +#define RV3028_CLKOUT_CLKOE BIT(7) >> + >> +#defi
Re: [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building highbank_defconfig with LTO, the compiler complains about > type mismatch of function ahci_link_up(). > > The third parameter of this function is of type u8 in > drivers/ata/ahci.c, but of type int in board/highbank/ahci.c. > > There is no reason in using u8, and the code using this function > actually passes an int variable into the function (so it is implicitly > converted to u8). > > Change the type of this parameter to int in drivers/ata/ahci.c. > > Signed-off-by: Marek Behún > --- > drivers/ata/ahci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building with LTO, the compiler complains about type mismatch of > function usb_gadget_handle_interrupts(). This function is defined > without parameters in files > arch/arm/mach-rockchip/board.c > board/samsung/common/exynos5-dt.c > but it should have one parameter, int index. > > Fix this. > > Signed-off-by: Marek Behún > --- > arch/arm/mach-rockchip/board.c| 2 +- > board/samsung/common/exynos5-dt.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() type mismatch for LTO
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building imx8mp_evk_defconfig with LTO, the compiler complains > about type mismatch of function imx_eqos_txclk_set_rate() in file > drivers/net/dwc_eth_qos.c:845:12 > which contains a weak definition of this function, vs file > arch/arm/mach-imx/imx8m/clock_imx8mm.c > which contains an implementation. > > Change the type of this function in the implementation to fix this. > > Signed-off-by: Marek Behún > --- > arch/arm/mach-imx/imx8m/clock_imx8mm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When building with LTO, the compiler complains about type mismatch of > function clk_bsc_enable() in file: > arch/arm/cpu/armv7/kona-common/clk-stubs.c > vs other files that define or use this function: > warning: type of ‘clk_bsc_enable’ does not match original declaration. > > Change the type of this function to that of the other usages. > > Signed-off-by: Marek Behún > --- > arch/arm/cpu/armv7/kona-common/clk-stubs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > When imx28_xea_defconfig is built with LTO, the compiler complains about > the two different declarations of _start: >include/asm-generic/sections.has extern void _start(void); >arch/arm/cpu/arm926ejs/mxs/mxs.c as extern uint32_t _start; > > Fix this. > > Signed-off-by: Marek Behún > --- > arch/arm/cpu/arm926ejs/mxs/mxs.c | 2 +- > arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH u-boot 22/39] sandbox: enable LTO by default
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > Build sandbox targets with LTO by default. > > Signed-off-by: Marek Behún > --- > arch/Kconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng
Re: [PATCH u-boot 21/39] sandbox: make LTO available
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote: > > Make LTO available for sandbox architecture. > > Signed-off-by: Marek Behún > --- > arch/Kconfig | 1 + > arch/sandbox/config.mk | 2 ++ > 2 files changed, 3 insertions(+) > Reviewed-by: Bin Meng
[PATCH v2] rtc: add support for rv3028 rtc
Add support for rtc3028 rtc from microcrystal. based on linux dirver: commit a38fd8748464: ("Linux 5.12-rc2") Signed-off-by: Heiko Schocher Reviewed-by: Stefan Roese --- Driver is based on code in linux, but with already corrected weekday usage. Linux codes the weekday bitwise, while the weekday register has only 3 valid bits as the app manual [1] says: This register holds the current day of the week. Each value represents one weekday that is assigned by the user. Values will range from 0 to 6 The weekday counter is simply a 3-bit counter which counts up to 6 and then resets to 0. [1] https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf This is not a big problem, as userspace never use weekday. Nevertheless, sent an update for the linux driver also: https://marc.info/?l=linux-rtc&m=161529769106774&w=2 azure build: https://dev.azure.com/hs0298/hs/_build/results?buildId=64&view=results Changes in v2: - add comments from Stefan - start sentence with upper-case - remove not needed includes, thanks! - add Reviewed-by from Stefan drivers/rtc/Kconfig | 6 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rv3028.c | 208 +++ 3 files changed, 215 insertions(+) create mode 100644 drivers/rtc/rv3028.c diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index aa6d90158c..e451308b40 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -95,6 +95,12 @@ config RTC_PCF8563 If you say yes here you get support for the Philips PCF8563 RTC and compatible chips. +config RTC_RV3028 + bool "Enable RV3028 driver" + depends on DM_RTC + help + The MicroCrystal RV3028 is a I2C Real Time Clock (RTC) + config RTC_RV3029 bool "Enable RV3029 driver" depends on DM_RTC diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 6a45a9c874..e7acd76266 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o obj-$(CONFIG_RTC_PL031) += pl031.o obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o +obj-$(CONFIG_RTC_RV3028) += rv3028.o obj-$(CONFIG_RTC_RV3029) += rv3029.o obj-$(CONFIG_RTC_RV8803) += rv8803.o obj-$(CONFIG_RTC_RX8025) += rx8025.o diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c new file mode 100644 index 00..9f63afc14a --- /dev/null +++ b/drivers/rtc/rv3028.c @@ -0,0 +1,208 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * RTC driver for the Micro Crystal RV3028 + * + * based on linux driver from + * Copyright (C) 2019 Micro Crystal SA + * + * Alexandre Belloni + * + */ + +#include +#include +#include + +#define RV3028_SEC 0x00 +#define RV3028_MIN 0x01 +#define RV3028_HOUR0x02 +#define RV3028_WDAY0x03 +#define RV3028_DAY 0x04 +#define RV3028_MONTH 0x05 +#define RV3028_YEAR0x06 +#define RV3028_ALARM_MIN 0x07 +#define RV3028_ALARM_HOUR 0x08 +#define RV3028_ALARM_DAY 0x09 +#define RV3028_STATUS 0x0E +#define RV3028_CTRL1 0x0F +#define RV3028_CTRL2 0x10 +#define RV3028_EVT_CTRL0x13 +#define RV3028_TS_COUNT0x14 +#define RV3028_TS_SEC 0x15 +#define RV3028_RAM10x1F +#define RV3028_EEPROM_ADDR 0x25 +#define RV3028_EEPROM_DATA 0x26 +#define RV3028_EEPROM_CMD 0x27 +#define RV3028_CLKOUT 0x35 +#define RV3028_OFFSET 0x36 +#define RV3028_BACKUP 0x37 + +#define RV3028_STATUS_PORF BIT(0) +#define RV3028_STATUS_EVF BIT(1) +#define RV3028_STATUS_AF BIT(2) +#define RV3028_STATUS_TF BIT(3) +#define RV3028_STATUS_UF BIT(4) +#define RV3028_STATUS_BSF BIT(5) +#define RV3028_STATUS_CLKF BIT(6) +#define RV3028_STATUS_EEBUSY BIT(7) + +#define RV3028_CLKOUT_FD_MASK GENMASK(2, 0) +#define RV3028_CLKOUT_PORIEBIT(3) +#define RV3028_CLKOUT_CLKSYBIT(6) +#define RV3028_CLKOUT_CLKOEBIT(7) + +#define RV3028_CTRL1_EERD BIT(3) +#define RV3028_CTRL1_WADA BIT(5) + +#define RV3028_CTRL2_RESET BIT(0) +#define RV3028_CTRL2_12_24 BIT(1) +#define RV3028_CTRL2_EIE BIT(2) +#define RV3028_CTRL2_AIE BIT(3) +#define RV3028_CTRL2_TIE BIT(4) +#define RV3028_CTRL2_UIE BIT(5) +#define RV3028_CTRL2_TSE BIT(7) + +#define RV3028_EVT_CTRL_TSRBIT(2) + +#define RV3028_EEPROM_CMD_UPDATE 0x11 +#define RV3028_EEPROM_CMD_WRITE0x21 +#define RV3028_EEPROM_CMD_READ 0x22 + +#define RV3028_EEBUSY_POLL
Re: [IMPORTANT] gitlab relocation / rename
Dear Henning, In message <20210308083457.76db0...@md1za8fc.ad001.siemens.net> you wrote: > > I do not understand why this is not just gitlab (proper) or github. I > hope this discussion was held with the communities of the affected > projects involved. While being disruptive i would suggest for Xenomai > to move away from denx. For the git side of the operations. To be more > open and welcoming to users/contributers etc. Are you positively sure that moving to any otherhosting environment will have any positive effect on how the Xenomai community works? We use the very same setup for U-Boot as well, which has a _much_ bigger and _much_ more active community. We have regular releases every 3 months, and most releases include commits from >200 developers from >30 employers. And the CI setup for U-Boot is in no respect (number of supported architectures / processors / boards / tool chains) less challenging than what you do in Xenomai, on contrary. Not to mention the development rate - U-Boot sees > 20 commits per day in mainline. Sorry, but I don't buy your "more open and welcoming to users/contri- buters" comment. THe existing environment has proven to work fine for a FOSS community project. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Someone who thinks logically is a nice contrast to the real world.