Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On 11/6/21 02:52, Andre Przywara wrote: On Fri, 5 Nov 2021 18:56:34 -0400 Tom Rini wrote: On Fri, Nov 05, 2021 at 09:38:50PM +0100, Heinrich Schuchardt wrote: On 11/5/21 20:17, Tom Rini wrote: On Fri, Nov 05, 2021 at 07:37:02PM +0100, Heinrich Schuchardt wrote: On 11/5/21 17:12, Simon Glass wrote: Hi, On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: Hi Andre, Added Tom to Cc. On 05.11.21 11:04, Andre Przywara wrote: On Thu, 4 Nov 2021 20:02:41 -0600 Simon Glass wrote: Hi, On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: Hi Andre, On 05.11.21 00:11, Andre Przywara wrote: On Thu, 4 Nov 2021 11:37:57 +0100 Stefan Roese wrote: Hi Stefan, On 04.11.21 04:55, Samuel Holland wrote: This series hooks up the watchdog uclass to automatically register watchdog devices for use with sysreset, doing a bit of minor cleanup along the way. The goal is for this to replace the sunxi board-level non-DM reset_cpu() function. I was surprised to find that the wdt_reboot driver requires its own undocumented device tree node, which references the watchdog device by phandle. This is problematic for us, because sunxi-u-boot.dtsi file covers 20 different SoCs with varying watchdog node phandle names. So it would have required adding a -u-boot.dtsi file for each board. Hooking things up automatically makes sense to me; this is what Linux does. However, I put the code behind a new option to avoid surprises for other platforms. Changes in v3: - Move condition to wdt-uclass.c to fix build errors. - Include watchdog name in error message. Changes in v2: - Extend the "if SYSRESET" block to the end of the file. - Also make gpio_reboot_probe function static. - Rebase on top of 492ee6b8d0e7 (now handle all watchdogs). - Added patches 5-6 as an example of how the new option will be used. Samuel Holland (6): sysreset: Add uclass Kconfig dependency to drivers sysreset: Mark driver probe functions as static sysreset: watchdog: Move watchdog reference to plat data watchdog: Automatically register device with sysreset sunxi: Avoid duplicate reset_cpu with SYSRESET enabled sunxi: Use sysreset framework for poweroff/reset arch/arm/Kconfig | 3 +++ arch/arm/mach-sunxi/board.c | 2 ++ drivers/sysreset/Kconfig | 11 ++-- drivers/sysreset/sysreset_gpio.c | 2 +- drivers/sysreset/sysreset_resetctl.c | 2 +- drivers/sysreset/sysreset_syscon.c | 2 +- drivers/sysreset/sysreset_watchdog.c | 40 ++-- drivers/watchdog/wdt-uclass.c| 8 ++ include/sysreset.h | 10 +++ 9 files changed, 67 insertions(+), 13 deletions(-) Applied to u-boot-marvell Mmmh, why u-boot-marvell, Because I'm handling watchdog related changed since a few years and we did not create a specific subsystem repo for this and I'm usually using my "marvell" one for this. And fwiw, there's a few other cases like this. If it's too confusing, maybe we should just roll out a few more repositories, I think it's easier to do that now than pre-gitlab? and why did this end up already in master? Isn't that material for the next merge window? After all this changes quite a bit, for a lot of boards, and I did not have a closer look at the sunxi parts yet. I was hesitating also a bit. But since this patchset is on the list in v1 since over 2 months now (2021-08-21) I thought it was "ready" for inclusion now. We are at -rc1 and I think we still have enough time to fix any resulting problems in this release cycle. Why do we have the merge window then? This is clearly not a regression or general fix. AFAIU, we are a bit less strict here in U-Boot. Patches that were posted before the merge-window and skipped the review process (most likely because of lack of time) are often still integrated in the early rcX cycles. At least this is how I handle it usually. Tom, is my understanding here correct? Yes. We are not as strict as the kernel is about what can come in between rc1 and rc2 (and to a certain degree, post rc2). I leave things up to the discretion of the custodians. People tend of have less time to handle U-Boot changes than other stuff, so I try and be flexible in picking things up. Yes I agree, that should be plenty of time for people to review it. Well, if there would be people to review the sunxi parts :-( I am totally fine with the generic patches (as they have been reviewed), but the sunxi integration is somewhat risky. I was explicitly deprioritising that in my queue, as it really doesn't change, add or fix anything, it's mere refactoring, from the user's point of view. Do you see any specific issues? Patch 6/6 changes the config for all 157 Allwinner boards, so I think that deserves at least some
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
Hi Pali, On Fri, Nov 5, 2021 at 5:10 PM Pali Rohár wrote: > > On Friday 05 November 2021 16:36:47 Tony Dinh wrote: > > Hi Pali, > > > > On Fri, Nov 5, 2021 at 3:15 PM Pali Rohár wrote: > > > > > > On Friday 05 November 2021 15:07:17 Tony Dinh wrote: > > > > > > Also, I have several Kirkwood boards (with various old BootROM > > > > > > versions) that I can run the kwboot tests on. Will keep you posted. > > > > > > > > > > Ok! Do you have some Kirkwood board with PCIe slot? If yes, I would > > > > > like > > > > > to see dumps from config space of Kirkwood PCIe Root Port, see: > > > > > https://lore.kernel.org/u-boot/20211104154921.b6zxjpczj7t6qlct@pali/ > > > > > > > > I have these Kirwood boards with PCI: > > > > - No slot (host bus for USB 3.0): Pogoplug V4 (6192), Zyxel NSA325v2 > > > > (6282). These 2 boards can be kwboot. > > > > - Iomega iConnect (6281), with PCIe slot for Wifi card. This board > > > > does not have kwboot booting support. > > > > > > What do you mean that it 'does not have kwboot booting support'? > > > 88F6281 is also Kirkwood and UART booting with kwboot should work. > > > > Most of the Kirkwood boards do have UART booting support. However, in > > my past experience, some Kirkwood boxes did not work with kwboot > > booting. It was observed experimentally that certain BootROM versions > > (depending on the time of manufacturing) on the 88F6281 SoC have > > problems with UART booting. But we have not proven this to be the real > > reason. These boards failed UART booting (the behavior is like the > > UART magic string handshake never occur): > > > > Seagate Dockstar (all), Iomega iConnect (all), Sheevaplug (some models > > probably do work), Seagate GoFlex Net (most boxes work, but a few > > models don't, and they have a different BootROM version from ones that > > do work). > > Hmm... ok. Maybe some bootrom versions have broken UART booting. > > During experiment with A385 I observed that it is needed to send > continuous stream of boot pattern without delay, so bootrom can properly > detect it and enter UART booting. But after bootrom is in UART booting > mode, it responds only when do not transmitting anything for some few > milliseconds. > So it is needed to solve two timing issues. First with upper bound (you > cannot use large delay as bootrom does not detect boot pattern) and > second with lower bound (you cannot use small delay as bootrom does not > answer). Plus another issue that linux kernel does provide asynchronous > tty API which could tell when output buffer was transmitted via UART. That's exactly what I've found trying to boot the Thecus N2350 (Armada 385). I've tried various -q -s parameters but could not find the right combination! OTOH, the Zyxel NAS326 (Armada 380) is OK with just the default timing (still more work on my part in the u-boot image, but kwboot started OK). > > If some bootrom versions are too much timing sensitive and you do not > know exact characteristic of it (and also of UART HW on the host) then > it could be hard or impossible to enter that UART boot mode. I've always suspected the box UART HW is the reason for failure to handshake, not the BootROM. But I'll try testing the old Kirkwood boxes again with the new kwboot to be sure. > I'm planning to rewrite kwboot code which is sending boot pattern to be > more precise on timings... So if you are interested in testing it, I > could do it in a way with more configurable delays... once I would have > some time for it. I'll be glad to test any new kwboot code you will have. My main interest is the Armada 38x and all Kirkwood boards. > > You could try to use tools/mrvl_uart.sh instead of kwboot. It implements > also code for sending boot pattern. But it requires valid image with > UART signature, it does not support on-the-fly patching like kwboot. That's what I did to boot the stock Thecus N2350 u-boot UART version. An old version of this mrvl_uart.sh script has been on the net for quite some time. But kwboot is more robust in the timing setup and allows us to boot the final version that will be flashed. > > > > I'll take a look at your link above and get back to you about the > > > > config space dumps. > > > > > > > > By the way, I'm starting to look at the driver/pci/pci_mvebu.c to see > > > > if it can be made to work with Kirkwood SoCs. I think there are many > > > > differences in the addresses and memory space. I would appreciate it > > > > if you have a general assessment whether I can use that driver for > > > > Kirkwood. > > > > > > pci_mvebu.c should work with Kirkwood SoCs and also with all these > > > 32-bit Marvell SoCs: Orion, Discovery, Kirkwood, Dove, A370, AXP, A375, > > > A38x and A39x. According to Functional Specifications all these SoCs > > > have common PCIe register set. > > > > That's great to hear! > > > > > > > > If there is any issue with it, I could try to look at it. > > > > At the moment, pci_mvebu.c is not included in the build for Kirkwood > > boards
Re: [RFC PATCH 00/13] Add support for Allwinner R329
On 7/22/21 1:30 AM, Icenowy Zheng wrote: > This patchset adds Allwinner R329 support to U-Boot. > > First, some code refactors happen for SoCs w/o SCP/MMC2. > > Then the basical support for R329 come as several parts (memory map, > clocks, pinmux, DRAM, final Kconfig option). > > Then, as the RFC part of this patchset, some device tree related > changes. > > Finally it comes the defconfig file for a R329 board, Sipeed Maix IIA > Dock. I was able to boot into Linux on my MaixSense, but I also needed the top patch from your branch here: https://github.com/sipeed/u-boot/commits/r329-wip Otherwise, U-Boot complained that $kernel_addr_r overlapped reserved memory. > This patchset is RFC mainly because of the DT-related part, as no DT > binding is mainlined in Linux now (it's still WIP). All other patches > are ready for being reviewed and, if proper, merged. Yes, I would like to have the Kconfig available so I can support R329 in my pinctrl series. Regards, Samuel
Re: [PATCH v1 1/2] image: Fix typo in boot_get_kbd()
On Fri, 5 Nov 2021 at 14:10, Andy Shevchenko
wrote:
>
> After the commit 4ed37abc49c2 ("image: Remove ifdefs around
> image_setup_linux() el at"):
>
> common/image-board.c: In function ‘boot_get_kbd’:
> common/image-board.c:902:17: error: expected ‘)’ before ‘do_bdinfo’
> 902 | do_bdinfo(NULL, 0, 0, NULL);
> | ^
> common/image-board.c:901:12: note: to match this ‘(’
> 901 | if (IS_ENABLED(CONFIG_CMD_BDI)
> |^
> common/image-board.c:906:1: error: expected expression before ‘}’ token
> 906 | }
> | ^
> common/image-board.c:906:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> 906 | }
> | ^
>
> Fix obvious typo.
>
> Fixes: 4ed37abc49c2 ("image: Remove ifdefs around image_setup_linux() el at")
> Signed-off-by: Andy Shevchenko
>
> Revert "image: Partially revert too aggressive ifdeferry removal"
>
> This reverts commit 84631af9d0454ff8252c1aebb1e9c232b8077692.
>
> Signed-off-by: Andy Shevchenko
> ---
> common/image-board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass
Re: [PATCH v1 2/2] image: Explicitly declare do_bdinfo()
Hi Andy, On Fri, 5 Nov 2021 at 14:10, Andy Shevchenko wrote: > > Compiler is not happy: > > common/image-board.c: In function ‘boot_get_kbd’: > common/image-board.c:902:17: warning: implicit declaration of function > ‘do_bdinfo’ [-Wimplicit-function-declaration] > 902 | do_bdinfo(NULL, 0, 0, NULL); > | ^ > > Move the forward declaration to a header. > > Signed-off-by: Andy Shevchenko > --- > common/image.c | 5 - > include/init.h | 5 + > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/common/image.c b/common/image.c > index 3fa60b582796..57bf86278149 100644 > --- a/common/image.c > +++ b/common/image.c > @@ -29,11 +29,6 @@ > #include > #include > > -#ifdef CONFIG_CMD_BDI > -extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, > -char *const argv[]); > -#endif > - > DECLARE_GLOBAL_DATA_PTR; > > /* Set this if we have less than 4 MB of malloc() space */ > diff --git a/include/init.h b/include/init.h > index c781789e367e..37ca9905414f 100644 > --- a/include/init.h > +++ b/include/init.h > @@ -332,6 +332,11 @@ void bdinfo_print_mhz(const char *name, unsigned long > hz); > /* Show arch-specific information for the 'bd' command */ > void arch_print_bdinfo(void); > > +#if defined(CONFIG_CMD_BDI) > +extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, > +char *const argv[]); > +#endif Can we drop the #if..#endif? > + > #endif /* __ASSEMBLY__ */ > /* Put only stuff here that the assembler can digest */ > > -- > 2.33.0 > Regards, SImon
Re: [PATCH] usb: Use the first available device for ehci_gadget
On Fri, 5 Nov 2021 at 10:53, Sean Anderson wrote: > > For whatever reason, usb_setup_ehci_gadget removes and probes USB device > 0. However, not all systems have a device 0. Use the first device > instead. > > The device probed should probably have something to do with the > controller (as specified by e.g. ums or fastboot > ). In fact, I find it odd that we probe the USB device in > the first place, because this is just to set up the gadget itself. > Presumably, the controller should be probed by usb_gadget_initialize > somehow. > > Signed-off-by: Sean Anderson > --- > > drivers/usb/host/usb-uclass.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: rk3399-gru-kevin: issues on bringup
Hi Alper, On Tue, 2 Nov 2021 at 17:05, Simon Glass wrote: > > Hi Alpher, > > On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak > wrote: > > > > Hi, > > > > I've had some recent success with my gru-kevin and wanted to update you > > on this. Long story short, I can boot from SPI flash and have the > > display, keyboard, eMMC, microSD card, USB disks all work (however with > > some hacks); but can't boot into Linux. Things seem to hang shortly > > after "Starting kernel..." but I don't know if something fails in U-Boot > > or if I get a kernel panic. (I still have no serial console). > > > > There are three relevant branches on my GitHub repo now, please have a > > look. The first is for what I intend to send upstream soon enough. The > > other two include hacks and additional patches that build on top of the > > first, meant to improve things on a per-board basis: > > > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob > > > > I have no idea if the gru-bob versions work. I just thought things I did > > for gru-kevin are applicable to it as well and decided I should include > > them in case anyone wants to test. > > > > > > I also want to ask you some things I'm indecisive about, before posting > > the rk3399-gru-chromebooks branch as patches. > > > > Most of the patches are small config and dts changes that I've grouped > > by whatever effect they have. Should I squash them into one commit each > > for config/dts? > > Probably best. > > > > > Simon, I've edited some of your patches and kept you as author & > > sign-off. Are you OK with the edited versions, am I doing things right? See: > > > > > > https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f9339efa8f7 > > > > https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc847d785f60 > > > > https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18634a1ebf > > LGTM > > > > > Marty, your (second) chromebook_kevin support patch didn't have your > > sign-off. Is it OK to add it? See: > > > > > > https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc4b5a8329 > > > > I also think I should squash my gru-kevin changes into that commit, add > > a commit message about board status, and keep Marty as author & sign-off > > while adding myself as Co-authored-by & sign-off. Any better ideas on > > how to structure the patches? > > > > Do both of you want to be in /board/google/gru/MAINTAINERS? I have three > > of us listed there right now, but no idea if that's fine with you two. > > > > Hope you can spare time on this. > > I actually have bob in my lab but I have not tried the Chrome OS boot > script on it. I could probably add kevin. > > $ do-try-int.sh bob > Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob > > Checking revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a > /vid/software/devel/ubtest > tbot starting ... > ├─Parameters: > │ rev= '77680d8f85b94ffe690b8fe1f35767aef8b1415a' > │ clean = False > ├─Calling uboot_build_and_flash ... > │ ├─bob is on port 9904 and uses /dev/pts/39 > │ ├─POWERON (bob) > │ ├─Calling uboot_build ... > │ │ ├─Calling uboot_checkout ... > │ │ │ ├─Builder: bob > │ │ │ └─Done. (1.038s) > │ │ ├─Configuring build ... > │ │ ├─Calling uboot_make ... > │ │ │ └─Done. (9.073s) > │ │ └─Done. (10.454s) > │ ├─Calling uboot_flash ... > │ │ └─Done. (0.677s) > │ ├─POWEROFF (bob) > │ └─Done. (11.868s) > ├─ > └─SUCCESS (11.994s) > tbot starting ... > ├─Calling interactive_board ... > │ ├─bob is on port 9904 and uses /dev/pts/39 > │ ├─POWERON (bob) > │ ├─Entering interactive shell (CTRL+D to exit) ... > �Channel 0: LPDDR3, 933MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > Channel 1: LPDDR3, 933MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > 256B stride > > U-Boot SPL 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600) > Trying to boot from SPI > rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: > uclass_get_device_by_phandle_id: err=-19 > rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: > uclass_get_device_by_phandle_id: err=-19 > ns16550_serial serial@ff1a: pinctrl_select_state_full: > uclass_get_device_by_phandle_id: err=-19 > > > U-Boot 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600) > > Model: Google Bob > DRAM: 3.9 GiB > Cannot find regulator pwm init_voltage > MMC: mmc@fe32: 1, mmc@fe33: 0 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > Got rc -1, expected 100 > Failed to probe keyboard 'keyboard-controller' > In:serial@ff1a > Out: serial@ff1a > Err: serial@ff1a > Model: Google Bob > Net: No ethernet found. > Hit any key to
Re: [RFC PATCH 12/13] sunxi: sync R329 DTs from internal WIP kernel tree
On 7/22/21 1:30 AM, Icenowy Zheng wrote: > Signed-off-by: Icenowy Zheng > --- > arch/arm/dts/Makefile | 2 + > arch/arm/dts/sun50i-r329-maix-iia-dock.dts | 36 > arch/arm/dts/sun50i-r329-maix-iia.dtsi | 45 + > arch/arm/dts/sun50i-r329.dtsi | 225 + > 4 files changed, 308 insertions(+) > create mode 100644 arch/arm/dts/sun50i-r329-maix-iia-dock.dts > create mode 100644 arch/arm/dts/sun50i-r329-maix-iia.dtsi > create mode 100644 arch/arm/dts/sun50i-r329.dtsi One thing to note when you rebase: you will need to add the watchdog node for rebooting to work. Regards, Samuel
Re: [RFC PATCH 11/13] mmc: sunxi: add support for R329 MMC controller
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> R329 SoC has similar MMC controllers with previous Allwinner SoCs.
>
> Add support for it by adding its compatible string.
>
> Signed-off-by: Icenowy Zheng
It really is that simple; as far as I can tell, the other checks are
covered by CONFIG_SUN50I_GEN_H6.
Reviewed-by: Samuel Holland
> ---
> drivers/mmc/sunxi_mmc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 6b809c001f..59cc28794d 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -734,6 +734,7 @@ static const struct udevice_id sunxi_mmc_ids[] = {
> { .compatible = "allwinner,sun50i-h6-emmc" },
> { .compatible = "allwinner,sun50i-a100-mmc" },
> { .compatible = "allwinner,sun50i-a100-emmc" },
> + { .compatible = "allwinner,sun50i-r329-mmc" },
> { /* sentinel */ }
> };
>
>
Re: [RFC PATCH 10/13] clk: sunxi: add support for R329 in sunxi DM clock driver
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> Currently only a subset of clocks/resets (similar to other SoCs) are
> supported.
>
> Signed-off-by: Icenowy Zheng
Reviewed-by: Samuel Holland
> ---
> drivers/clk/sunxi/Kconfig| 7 +++
> drivers/clk/sunxi/Makefile | 1 +
> drivers/clk/sunxi/clk_r329.c | 94
> 3 files changed, 102 insertions(+)
> create mode 100644 drivers/clk/sunxi/clk_r329.c
>
> diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
> index bf084fa7a8..8dd3be4683 100644
> --- a/drivers/clk/sunxi/Kconfig
> +++ b/drivers/clk/sunxi/Kconfig
> @@ -86,6 +86,13 @@ config CLK_SUN50I_H616
> This enables common clock driver support for platforms based
> on Allwinner H616 SoC.
>
> +config CLK_SUN50I_R329
> + bool "Clock driver for Allwinner R329"
> + default MACH_SUN50I_R329
> + help
> + This enables common clock driver support for platforms based
> + on Allwinner R329 SoC.
> +
> config CLK_SUN50I_A64
> bool "Clock driver for Allwinner A64"
> default MACH_SUN50I
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 4f9282a8b9..050f7ecc46 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -19,4 +19,5 @@ obj-$(CONFIG_CLK_SUN9I_A80) += clk_a80.o
> obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
> obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
> obj-$(CONFIG_CLK_SUN50I_H616) += clk_h616.o
> +obj-$(CONFIG_CLK_SUN50I_R329) += clk_r329.o
> obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
> diff --git a/drivers/clk/sunxi/clk_r329.c b/drivers/clk/sunxi/clk_r329.c
> new file mode 100644
> index 00..17157214b6
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk_r329.c
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2021 Sipeed
> + * Based on clk_h616.c, which is:
> + * Copyright (C) 2021 Jernej Skrabec
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
This will need to be updated when you rebase:
#include
Regards,
Samuel
> +#include
> +#include
> +#include
> +
> +static struct ccu_clk_gate r329_gates[] = {
> + [CLK_BUS_MMC0] = GATE(0x84c, BIT(0)),
> + [CLK_BUS_MMC1] = GATE(0x84c, BIT(1)),
> +
> + [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
> + [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
> + [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
> + [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
> +
> + [CLK_SPI0] = GATE(0x940, BIT(31)),
> + [CLK_SPI1] = GATE(0x944, BIT(31)),
> +
> + [CLK_BUS_SPI0] = GATE(0x96c, BIT(0)),
> + [CLK_BUS_SPI1] = GATE(0x96c, BIT(1)),
> +
> + [CLK_BUS_EMAC] = GATE(0x97c, BIT(0)),
> +
> + [CLK_USB_PHY0] = GATE(0xa70, BIT(29)),
> + [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
> +
> + [CLK_USB_PHY1] = GATE(0xa74, BIT(29)),
> + [CLK_USB_OHCI1] = GATE(0xa74, BIT(31)),
> +
> + [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
> + [CLK_BUS_OHCI1] = GATE(0xa8c, BIT(1)),
> + [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
> + [CLK_BUS_OTG] = GATE(0xa8c, BIT(8)),
> +};
> +
> +static struct ccu_reset r329_resets[] = {
> + [RST_BUS_MMC0] = RESET(0x84c, BIT(16)),
> + [RST_BUS_MMC1] = RESET(0x84c, BIT(17)),
> +
> + [RST_BUS_UART0] = RESET(0x90c, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x90c, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x90c, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x90c, BIT(19)),
> +
> + [RST_BUS_SPI0] = RESET(0x96c, BIT(16)),
> + [RST_BUS_SPI1] = RESET(0x96c, BIT(17)),
> +
> + [RST_BUS_EMAC] = RESET(0x97c, BIT(16)),
> +
> + [RST_USB_PHY0] = RESET(0xa70, BIT(30)),
> +
> + [RST_USB_PHY1] = RESET(0xa74, BIT(30)),
> +
> + [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)),
> + [RST_BUS_OHCI1] = RESET(0xa8c, BIT(17)),
> + [RST_BUS_EHCI0] = RESET(0xa8c, BIT(20)),
> + [RST_BUS_OTG] = RESET(0xa8c, BIT(24)),
> +};
> +
> +static const struct ccu_desc r329_ccu_desc = {
> + .gates = r329_gates,
> + .resets = r329_resets,
> +};
> +
> +static int r329_clk_bind(struct udevice *dev)
> +{
> + return sunxi_reset_bind(dev, ARRAY_SIZE(r329_resets));
> +}
> +
> +static const struct udevice_id r329_ccu_ids[] = {
> + { .compatible = "allwinner,sun50i-r329-ccu",
> + .data = (ulong)_ccu_desc },
> + { }
> +};
> +
> +U_BOOT_DRIVER(clk_sun50i_r329) = {
> + .name = "sun50i_r329_ccu",
> + .id = UCLASS_CLK,
> + .of_match = r329_ccu_ids,
> + .priv_auto = sizeof(struct ccu_priv),
> + .ops= _clk_ops,
> + .probe = sunxi_clk_probe,
> + .bind = r329_clk_bind,
> +};
>
Re: [RFC PATCH 08/13] sunxi: add Kconfig option for R329
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> As most code are ready for basic R329 support, let's add a Kconfig
> option for it.
>
> Signed-off-by: Icenowy Zheng
Reviewed-by: Samuel Holland
with one minor comment below.
> ---
> arch/arm/mach-sunxi/Kconfig| 14 +-
> arch/arm/mach-sunxi/cpu_info.c | 2 ++
> common/spl/Kconfig | 1 +
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index c9bb47a8bd..9d3ec82497 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -128,6 +128,7 @@ config SUN8I_RSB
> config SUNXI_SRAM_ADDRESS
> hex
> default 0x1 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5
> + default 0x10 if MACH_SUN50I_R329
> default 0x2 if SUN50I_GEN_H6
> default 0x0
> ---help---
> @@ -371,6 +372,12 @@ config MACH_SUN50I_H616
> select DRAM_SUN50I_H616
> select SUN50I_GEN_H6
>
> +config MACH_SUN50I_R329
> + bool "sun50i (Allwinner R329)"
> + select ARM64
> + select DRAM_SUN50I_R329
> + select SUN50I_GEN_H6
> +
> endchoice
>
> # The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
> @@ -420,7 +427,8 @@ config SUNXI_DRAM_LPDDR3
>
> choice
> prompt "DRAM Type and Timing"
> - default SUNXI_DRAM_DDR3_1333 if !MACH_SUN8I_V3S
> + default SUNXI_DRAM_DDR3_1333 if !MACH_SUN8I_V3S && !MACH_SUN50I_R329
> + default SUNXI_DRAM_DDR3_R329 if MACH_SUN50I_R329
> default SUNXI_DRAM_DDR2_V3S if MACH_SUN8I_V3S
The first matching line is used, so you can reorder these to remove the
negations.
Regards,
Samuel
>
> config SUNXI_DRAM_DDR3_1333
> @@ -488,6 +496,7 @@ config DRAM_CLK
> MACH_SUN8I_V3S
> default 672 if MACH_SUN50I
> default 744 if MACH_SUN50I_H6
> + default 775 if MACH_SUN50I_R329
> default 720 if MACH_SUN50I_H616
> ---help---
> Set the dram clock speed, valid range 240 - 480 (prior to sun9i),
> @@ -510,6 +519,7 @@ config DRAM_ZQ
> MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_A83T
> default 127 if MACH_SUN7I
> default 14779 if MACH_SUN8I_V3S
> + default 3067 if MACH_SUN50I_R329
> default 3881979 if MACH_SUNXI_H3_H5 || MACH_SUN8I_R40 || MACH_SUN50I_H6
> default 4145117 if MACH_SUN9I
> default 3881915 if MACH_SUN50I
> @@ -616,6 +626,7 @@ config SYS_CLK_FREQ
> default 100800 if MACH_SUN9I
> default 88800 if MACH_SUN50I_H6
> default 100800 if MACH_SUN50I_H616
> + default 100800 if MACH_SUN50I_R329
>
> config SYS_CONFIG_NAME
> default "sun4i" if MACH_SUN4I
> @@ -627,6 +638,7 @@ config SYS_CONFIG_NAME
> default "sun50i" if MACH_SUN50I
> default "sun50i" if MACH_SUN50I_H6
> default "sun50i" if MACH_SUN50I_H616
> + default "sun50i" if MACH_SUN50I_R329
>
> config SYS_BOARD
> default "sunxi"
> diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
> index ba33ef2430..8021f4c307 100644
> --- a/arch/arm/mach-sunxi/cpu_info.c
> +++ b/arch/arm/mach-sunxi/cpu_info.c
> @@ -101,6 +101,8 @@ int print_cpuinfo(void)
> puts("CPU: Allwinner H6 (SUN50I)\n");
> #elif defined CONFIG_MACH_SUN50I_H616
> puts("CPU: Allwinner H616 (SUN50I)\n");
> +#elif defined CONFIG_MACH_SUN50I_R329
> + puts("CPU: Allwinner R329 (SUN50I)\n");
> #else
> #warning Please update cpu_info.c with correct CPU information
> puts("CPU: SUNXI Family\n");
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 2df3e5d869..ed4477ff93 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -150,6 +150,7 @@ config SPL_TEXT_BASE
> hex "SPL Text Base"
> default ISW_ENTRY_ADDR if AM43XX || AM33XX || OMAP54XX || ARCH_KEYSTONE
> default 0x10060 if MACH_SUN50I || MACH_SUN50I_H5 || MACH_SUN9I
> + default 0x100060 if MACH_SUN50I_R329
> default 0x20060 if SUN50I_GEN_H6
> default 0x00060 if ARCH_SUNXI
> default 0xfffc if ARCH_ZYNQMP
>
Re: [RFC PATCH 07/13] sunxi: add support for R329 DRAM controller
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> R329 has a new DRAM controller, which looks like a combination of the
> H6/H616 MCTL_COM part and the SUNXI_DW MCTL_CTL part. This design has
> already got reused by Allwinner, and V831/V833 SoCs have similar
> memory controller.
>
> Add support for it. To prepare for further support of other SoCs,
> routines with socid parameter are added, although not checked now.
>
> Signed-off-by: Icenowy Zheng
I cannot really review the DRAM init part. But it works, so that's
probably good enough.
Tested-by: Samuel Holland
There are a couple of magic values I happen to have an explanation for:
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_r329.c
> b/arch/arm/mach-sunxi/dram_sun50i_r329.c
> new file mode 100644
> index 00..730883999c
> --- /dev/null
> +++ b/arch/arm/mach-sunxi/dram_sun50i_r329.c
> ...> +unsigned long sunxi_dram_init(void)
> +{
> + struct sunxi_mctl_com_reg * const mctl_com =
> + (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> + struct sunxi_mctl_ctl_reg * const mctl_ctl =
> + (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> +
> + struct dram_para para = {
> + .dual_rank = 0,
> + .bus_full_width = 1,
> + .row_bits = 16,
> + .bank_bits = 3,
> + .page_size = 8192,
> +
> + .dx_read_delays = SUN50I_R329_DX_READ_DELAYS,
> + .dx_write_delays = SUN50I_R329_DX_WRITE_DELAYS,
> + .ac_delays = SUN50I_R329_AC_DELAYS,
> + };
> +
> + /* Unknown magic */
> + writel(0x10, 0x07010250);
This is VDD_SYS_POWEROFF_GATING_REG, presumably disabling pad hold.
> + writel(0x33, 0x07010310);
> + writel(0x330003, 0x07010310);
This is a resistor calibration process. See here:
https://github.com/smaeul/sun20i_d1_spl/blob/342cb1d8/include/arch/cpu_ncat.h#L172
https://github.com/smaeul/sun20i_d1_spl/blob/342cb1d8/board/sun20iw1p1/clock.c#L186
Some other BSP code has:
#define REG_CALIB_CONTROL_REG 0x0310
#define OHMS200_REG 0x0314
#define OHMS240_REG 0x0318
#define REG_CALIB_STATUS_REG0x031c
So this suggests we are calibrating the termination resistors.
Regards,
Samuel
> +
> +#if defined(CONFIG_MACH_SUN50I_R329)
> + uint16_t socid = SOCID_R329;
> +#endif
> +
> + mctl_sys_init();
> + if (mctl_channel_init(socid, ))
> + return 0;
> +
> + udelay(1);
> +
> + clrbits_le32(_ctl->unk_0x0a0, 0x);
> + clrbits_le32(_ctl->pwrctl, 0x1);
> +
> + /* HDR/DDR dynamic mode */
> + clrbits_le32(_ctl->pgcr[0], 0xf000);
> +
> + /* power down zq calibration module for power save */
> + setbits_le32(_ctl->zqcr, ZQCR_PWRDOWN);
> +
> + /* DQ hold disable (tpr13[26] == 1) */
> + clrbits_le32(_ctl->pgcr[2], (1 << 13));
> +
> + mctl_auto_detect_dram_size();
> + mctl_apply_para();
> +
> + /* enable master access */
> + writel(0x, _com->maer0);
> + writel(0x7f, _com->maer1);
> + writel(0x, _com->maer2);
> +
> + return (1UL << (para.row_bits + para.bank_bits)) * para.page_size *
> +(para.dual_rank ? 2 : 1);
> +}
Re: [RFC PATCH 06/13] sunxi: add support for basical pinmux setup on R329
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> Allwinner R329 SoC is the first known Allwinner SoC that has two
> possible pinmux setups for MMC0 controller.
>
> Support configuration of both setups of MMC0 and UART0 at PB4/5.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/include/asm/arch-sunxi/gpio.h | 3 +++
> arch/arm/mach-sunxi/Kconfig| 7 +++
> arch/arm/mach-sunxi/board.c| 4
> board/sunxi/board.c| 20
> 4 files changed, 34 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 2969a530ae..da9acfab78 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -166,12 +166,14 @@ enum sunxi_gpio_number {
> #define SUN8I_A83T_GPB_UART0 2
> #define SUN8I_V3S_GPB_UART0 3
> #define SUN50I_GPB_UART0 4
> +#define SUN50I_R329_GPB_UART02
>
> #define SUNXI_GPC_NAND 2
> #define SUNXI_GPC_SPI0 3
> #define SUNXI_GPC_SDC2 3
> #define SUN6I_GPC_SDC3 4
> #define SUN50I_GPC_SPI0 4
> +#define SUN50I_R329_GPC_SDC0 3
>
> #define SUN8I_GPD_SDC1 3
> #define SUNXI_GPD_LCD0 2
> @@ -185,6 +187,7 @@ enum sunxi_gpio_number {
> #define SUNXI_GPF_SDC0 2
> #define SUNXI_GPF_UART0 4
> #define SUN8I_GPF_UART0 3
> +#define SUN50I_R329_GPF_SDC0 5
>
> #define SUN4I_GPG_SDC1 4
> #define SUN5I_GPG_SDC1 2
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 49f94f095c..391a3dd9e5 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -672,6 +672,13 @@ config MMC3_CD_PIN
> ---help---
> See MMC0_CD_PIN help text.
>
> +config MMC0_PINS
> + string "Pins for mmc0"
> + default "PF"
> + depends on MACH_SUN50I_R329
> + ---help---
> + See MMC1_PINS help text.
> +
Please make this a Boolean MMC0_PINS_PC (this area was changed since you
sent these patches).
> config MMC1_PINS
> string "Pins for mmc1"
> default ""
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index e979e426dd..1aa31c7e05 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -129,6 +129,10 @@ static int gpio_init(void)
> sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H616_GPH_UART0);
> sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H616_GPH_UART0);
> sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
> +#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I_R329)
> + sunxi_gpio_set_cfgpin(SUNXI_GPB(4), SUN50I_R329_GPB_UART0);
> + sunxi_gpio_set_cfgpin(SUNXI_GPB(5), SUN50I_R329_GPB_UART0);
> + sunxi_gpio_set_pull(SUNXI_GPB(5), SUNXI_GPIO_PULL_UP);
> #elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_A83T)
> sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN8I_A83T_GPB_UART0);
> sunxi_gpio_set_cfgpin(SUNXI_GPB(10), SUN8I_A83T_GPB_UART0);
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 67acc01d83..bfc90345d9 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -417,12 +417,32 @@ static void mmc_pinmux_setup(int sdc)
>
> switch (sdc) {
> case 0:
> +#if defined(CONFIG_MACH_SUN50I_R329)
Please use if (IS_ENABLED(...)).
Regards,
Samuel
> + pins = sunxi_name_to_gpio_bank(CONFIG_MMC0_PINS);
> +
> + if (pins == SUNXI_GPIO_C) {
> + /* SDC0: PC0-PC6 */
> + for (pin = SUNXI_GPC(0); pin <= SUNXI_GPC(6); pin++) {
> + sunxi_gpio_set_cfgpin(pin,
> SUN50I_R329_GPC_SDC0);
> + sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> + sunxi_gpio_set_drv(pin, 2);
> + }
> + } else {
> + /* SDC0: PF0-PF5 */
> + for (pin = SUNXI_GPF(0); pin <= SUNXI_GPF(5); pin++) {
> + sunxi_gpio_set_cfgpin(pin,
> SUN50I_R329_GPF_SDC0);
> + sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> + sunxi_gpio_set_drv(pin, 2);
> + }
> + }
> +#else
> /* SDC0: PF0-PF5 */
> for (pin = SUNXI_GPF(0); pin <= SUNXI_GPF(5); pin++) {
> sunxi_gpio_set_cfgpin(pin, SUNXI_GPF_SDC0);
> sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> sunxi_gpio_set_drv(pin, 2);
> }
> +#endif
> break;
>
> case 1:
>
Re: [RFC PATCH 05/13] sunxi: add support for R329 clocks
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> R329 has a quite different clock tree than other SoCs. It has only 4
> PLLs and its PLL-PERIPH has two post dividers, one for the normal
> PLL-PERIPH-2x output and another for a special PLL-PERIPH-800M output.
> In addition, its PLL configuration registers are in PRCM memory zone,
> not the ordinary CPUX CCU one.
>
> Add support for basical R329 clock initialization.
>
> Signed-off-by: Icenowy Zheng
Reviewed-by: Samuel Holland
One minor comment below.
> ---
> arch/arm/mach-sunxi/clock_sun50i_h6.c | 49 ---
> 1 file changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> index a947463e0a..28bc5fccd8 100644
> --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> @@ -9,6 +9,13 @@ void clock_init_safe(void)
> {
> struct sunxi_ccm_reg *const ccm =
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> +#ifdef CONFIG_MACH_SUN50I_R329
> + struct sunxi_prcm_reg *const prcm =
> + (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
> + struct sunxi_prcm_reg *const pllccm = prcm;
> +#else
> + struct sunxi_ccm_reg *const pllccm = ccm;
> +#endif
>
> /* this seems to enable PLLs on H616 */
> if (IS_ENABLED(CONFIG_MACH_SUN50I_H616))
> @@ -16,22 +23,26 @@ void clock_init_safe(void)
>
> clock_set_pll1(40800);
>
> - writel(CCM_PLL6_DEFAULT, >pll6_cfg);
> - while (!(readl(>pll6_cfg) & CCM_PLL6_LOCK))
> + writel(CCM_PLL6_DEFAULT, >pll6_cfg);
> + while (!(readl(>pll6_cfg) & CCM_PLL6_LOCK))
> ;
>
> clrsetbits_le32(>cpu_axi_cfg, CCM_CPU_AXI_APB_MASK |
> CCM_CPU_AXI_AXI_MASK,
> CCM_CPU_AXI_DEFAULT_FACTORS);
>
> writel(CCM_PSI_AHB1_AHB2_DEFAULT, >psi_ahb1_ahb2_cfg);
> +#ifdef CCM_AHB3_DEFAULT
> writel(CCM_AHB3_DEFAULT, >ahb3_cfg);
> +#endif
> writel(CCM_APB1_DEFAULT, >apb1_cfg);
>
> +#ifndef CONFIG_MACH_SUN50I_R329
> /*
>* The mux and factor are set, but the clock will be enabled in
>* DRAM initialization code.
>*/
> writel(MBUS_CLK_SRC_PLL6X2 | MBUS_CLK_M(3), >mbus_cfg);
> +#endif
> }
> #endif
>
> @@ -60,8 +71,20 @@ void clock_set_pll1(unsigned int clk)
> {
> struct sunxi_ccm_reg * const ccm =
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> +#ifdef CONFIG_MACH_SUN50I_R329
> + struct sunxi_prcm_reg *const prcm =
> + (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
> + struct sunxi_prcm_reg *const pllccm = prcm;
> +#else
> + struct sunxi_ccm_reg *const pllccm = ccm;
> +#endif
> u32 val;
>
> +#ifdef CONFIG_MACH_SUN50I_R329
> + /* Fix undervoltage reset threshold */
> + clrsetbits_le32(0x070901f4, 0xfff, 0xc0);
> +#endif
> +
> /* Do not support clocks < 288MHz as they need factor P */
> if (clk < 28800) clk = 28800;
>
> @@ -73,11 +96,11 @@ void clock_set_pll1(unsigned int clk)
>
> /* clk = 24*n/p, p is ignored if clock is >288MHz */
> writel(CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2 |
> -#ifdef CONFIG_MACH_SUN50I_H616
> +#ifndef CONFIG_MACH_SUN50I_H6
> CCM_PLL1_OUT_EN |
> #endif
> -CCM_PLL1_CTRL_N(clk / 2400), >pll1_cfg);
> - while (!(readl(>pll1_cfg) & CCM_PLL1_LOCK)) {}
> +CCM_PLL1_CTRL_N(clk / 2400), >pll1_cfg);
> + while (!(readl(>pll1_cfg) & CCM_PLL1_LOCK)) {}
>
> /* Switch CPU to PLL1 */
> val = readl(>cpu_axi_cfg);
> @@ -87,6 +110,7 @@ void clock_set_pll1(unsigned int clk)
> }
> #endif
>
> +#ifndef CONFIG_MACH_SUN50I_R329
The negative condition here will make it messier to add more branches in
the future, so I suggest flipping the conditional block.
> unsigned int clock_get_pll6(void)
> {
> struct sunxi_ccm_reg *const ccm =
> @@ -102,6 +126,21 @@ unsigned int clock_get_pll6(void)
> /* The register defines PLL6-2X or PLL6-4X, not plain PLL6 */
> return 2400 / m * n / div1 / div2;
> }
> +#else
> +unsigned int clock_get_pll6(void)
> +{
> + struct sunxi_prcm_reg *const prcm =
> + (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
> +
> + uint32_t rval = readl(>pll6_cfg);
> + int m = ((rval & CCM_PLL6_CTRL_M_MASK) >> CCM_PLL6_CTRL_M_SHIFT) + 1;
> + int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
> + int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
> + CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
> + /* The register defines PLL6-2X, not plain PLL6 */
> + return 2400 / m * n / div1 / 2;
> +}
> +#endif
>
> int clock_twi_onoff(int port, int state)
> {
>
Re: [RFC PATCH 04/13] sunxi: add memory addresses for R329 SoC
On 7/22/21 1:30 AM, Icenowy Zheng wrote:
> Allwinner R329 SoC has a different memory map with previous post-H6
> SoCs.
>
> Add the memory map to a dedicated header file, fill everywhere that
> uses a hardcoded MMIO address and specify the SPL/ATF load address.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/cpu/armv8/fel_utils.S| 2 +-
> arch/arm/dts/sunxi-u-boot.dtsi| 2 +
> arch/arm/include/asm/arch-sunxi/boot0.h | 4 +-
> .../include/asm/arch-sunxi/clock_sun50i_h6.h | 17 ++
> arch/arm/include/asm/arch-sunxi/cpu.h | 2 +
> .../include/asm/arch-sunxi/cpu_sun50i_r329.h | 58 +++
> arch/arm/include/asm/arch-sunxi/prcm_sun50i.h | 33 +++
> include/configs/sunxi-common.h| 3 +
> 8 files changed, 119 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sun50i_r329.h
>
> diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
> index 7def44ad1d..aa16d79df9 100644
> --- a/arch/arm/cpu/armv8/fel_utils.S
> +++ b/arch/arm/cpu/armv8/fel_utils.S
> @@ -40,7 +40,7 @@ ENTRY(return_to_fel)
> str w2, [x1]
>
> ldr x0, =0xfa50392f // CPU hotplug magic
> -#ifdef CONFIG_MACH_SUN50I_H616
> +#if defined(CONFIG_MACH_SUN50I_H616) || defined(CONFIG_MACH_SUN50I_R329)
> ldr x2, =(SUNXI_R_CPUCFG_BASE + 0x1c0)
> str w0, [x2], #0x4
> #elif CONFIG_MACH_SUN50I_H6
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index b7244c1112..9bb6fffeb4 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -5,6 +5,8 @@
> #define SCP_ADDR 0x114000
> #elif defined(CONFIG_MACH_SUN50I_H616)
> #define BL31_ADDR 0x4000
> +#elif defined(CONFIG_MACH_SUN50I_R329)
> +#define BL31_ADDR 0x124000
This was changed to 0x0011 while upstreaming TF-A support. (I see
you already updated this in your branch.)
> #else
> #define BL31_ADDR 0x44000
> #define SCP_ADDR 0x5
> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
> b/arch/arm/include/asm/arch-sunxi/boot0.h
> index e8e8e38f05..a791c7c403 100644
> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> @@ -39,7 +39,9 @@
> .word 0xf57ff06f // isb sy
> .word 0xe320f003 // wfi
> .word 0xeafd // b @wfi
> -#ifndef CONFIG_SUN50I_GEN_H6
> +#if defined(CONFIG_MACH_SUN50I_R329)
> + .word 0x08100040 // writeable RVBAR mapping address
> +#elif !defined(CONFIG_SUN50I_GEN_H6)
> .word 0x017000a0 // writeable RVBAR mapping address
> #else
> .word 0x09010040 // writeable RVBAR mapping address
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> index 37df4410ea..6c3b8ea351 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> @@ -250,10 +250,19 @@ struct sunxi_ccm_reg {
> #define CCM_PLL6_LOCKBIT(28)
> #define CCM_PLL6_CTRL_N_SHIFT8
> #define CCM_PLL6_CTRL_N_MASK (0xff << CCM_PLL6_CTRL_N_SHIFT)
> +#ifndef CONFIG_MACH_SUN50I_R329
> #define CCM_PLL6_CTRL_DIV1_SHIFT 0
> #define CCM_PLL6_CTRL_DIV1_MASK (0x1 <<
> CCM_PLL6_CTRL_DIV1_SHIFT)
> #define CCM_PLL6_CTRL_DIV2_SHIFT 1
> #define CCM_PLL6_CTRL_DIV2_MASK (0x1 <<
> CCM_PLL6_CTRL_DIV2_SHIFT)
> +#else
> +#define CCM_PLL6_CTRL_M_SHIFT1
> +#define CCM_PLL6_CTRL_M_MASK (0x1 << CCM_PLL6_CTRL_DIV2_SHIFT)
This should be using CCM_PLL6_CTRL_M_SHIFT.
> +#define CCM_PLL6_CTRL_DIV1_SHIFT 16
> +#define CCM_PLL6_CTRL_DIV1_MASK (0x7 <<
> CCM_PLL6_CTRL_DIV1_SHIFT)
> +#define CCM_PLL6_CTRL_DIV2_SHIFT 20
> +#define CCM_PLL6_CTRL_DIV2_MASK (0x7 <<
> CCM_PLL6_CTRL_DIV2_SHIFT)
> +#endif
>
> /* cpu_axi bit field*/
> #define CCM_CPU_AXI_MUX_MASK (0x3 << 24)
> @@ -285,6 +294,14 @@ struct sunxi_ccm_reg {
>
> /* apb1 bit field */
> #define CCM_APB1_DEFAULT 0x03000102
> +#elif CONFIG_MACH_SUN50I_R329
> +#define CCM_PLL6_DEFAULT 0xa8216300
> +
> +/* ahb bit field */
> +#define CCM_PSI_AHB1_AHB2_DEFAULT0x0302
> +
> +/* apb1 bit field */
> +#define CCM_APB1_DEFAULT 0x0201
> #endif
>
> /* apb2 bit field */
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
> b/arch/arm/include/asm/arch-sunxi/cpu.h
> index b08f202374..20d04cac74 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
> @@ -8,6 +8,8 @@
>
> #if defined(CONFIG_MACH_SUN9I)
> #include
> +#elif defined(CONFIG_MACH_SUN50I_R329)
> +#include
> #elif defined(CONFIG_SUN50I_GEN_H6)
> #include
> #else
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_r329.h
> b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_r329.h
> new file
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On Fri, 5 Nov 2021 18:56:34 -0400 Tom Rini wrote: > On Fri, Nov 05, 2021 at 09:38:50PM +0100, Heinrich Schuchardt wrote: > > On 11/5/21 20:17, Tom Rini wrote: > > > On Fri, Nov 05, 2021 at 07:37:02PM +0100, Heinrich Schuchardt wrote: > > > > On 11/5/21 17:12, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: > > > > > > > > > > > > On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: > > > > > > > Hi Andre, > > > > > > > > > > > > > > Added Tom to Cc. > > > > > > > > > > > > > > On 05.11.21 11:04, Andre Przywara wrote: > > > > > > > > On Thu, 4 Nov 2021 20:02:41 -0600 > > > > > > > > Simon Glass wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > On Thu, 4 Nov 2021 at 19:22, Stefan Roese > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Andre, > > > > > > > > > > > > > > > > > > > > On 05.11.21 00:11, Andre Przywara wrote: > > > > > > > > > > > On Thu, 4 Nov 2021 11:37:57 +0100 > > > > > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Stefan, > > > > > > > > > > > > On 04.11.21 04:55, Samuel Holland wrote: > > > > > > > > > > > > > This series hooks up the watchdog uclass to > > > > > > > > > > > > > automatically register > > > > > > > > > > > > > watchdog devices for use with sysreset, doing a bit > > > > > > > > > > > > > of minor cleanup > > > > > > > > > > > > > along the way. > > > > > > > > > > > > > > > > > > > > > > > > > > The goal is for this to replace the sunxi board-level > > > > > > > > > > > > > non-DM reset_cpu() > > > > > > > > > > > > > function. I was surprised to find that the wdt_reboot > > > > > > > > > > > > > driver requires > > > > > > > > > > > > > its own undocumented device tree node, which > > > > > > > > > > > > > references the watchdog > > > > > > > > > > > > > device by phandle. This is problematic for us, > > > > > > > > > > > > > because sunxi-u-boot.dtsi > > > > > > > > > > > > > file covers 20 different SoCs with varying watchdog > > > > > > > > > > > > > node phandle names. > > > > > > > > > > > > > So it would have required adding a -u-boot.dtsi file > > > > > > > > > > > > > for each board. > > > > > > > > > > > > > > > > > > > > > > > > > > Hooking things up automatically makes sense to me; > > > > > > > > > > > > > this is what Linux > > > > > > > > > > > > > does. However, I put the code behind a new option to > > > > > > > > > > > > > avoid surprises for > > > > > > > > > > > > > other platforms. > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > > - Move condition to wdt-uclass.c to fix build > > > > > > > > > > > > > errors. > > > > > > > > > > > > > - Include watchdog name in error message. > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > > - Extend the "if SYSRESET" block to the end of > > > > > > > > > > > > > the file. > > > > > > > > > > > > > - Also make gpio_reboot_probe function static. > > > > > > > > > > > > > - Rebase on top of 492ee6b8d0e7 (now handle all > > > > > > > > > > > > > watchdogs). > > > > > > > > > > > > > - Added patches 5-6 as an example of how the > > > > > > > > > > > > > new option will be used. > > > > > > > > > > > > > > > > > > > > > > > > > > Samuel Holland (6): > > > > > > > > > > > > >sysreset: Add uclass Kconfig dependency to > > > > > > > > > > > > > drivers > > > > > > > > > > > > >sysreset: Mark driver probe functions as static > > > > > > > > > > > > >sysreset: watchdog: Move watchdog reference to > > > > > > > > > > > > > plat data > > > > > > > > > > > > >watchdog: Automatically register device with > > > > > > > > > > > > > sysreset > > > > > > > > > > > > >sunxi: Avoid duplicate reset_cpu with SYSRESET > > > > > > > > > > > > > enabled > > > > > > > > > > > > >sunxi: Use sysreset framework for > > > > > > > > > > > > > poweroff/reset > > > > > > > > > > > > > > > > > > > > > > > > > > arch/arm/Kconfig | 3 +++ > > > > > > > > > > > > > arch/arm/mach-sunxi/board.c | 2 ++ > > > > > > > > > > > > > drivers/sysreset/Kconfig | 11 > > > > > > > > > > > > > ++-- > > > > > > > > > > > > > drivers/sysreset/sysreset_gpio.c | 2 +- > > > > > > > > > > > > > drivers/sysreset/sysreset_resetctl.c | 2 +- > > > > > > > > > > > > > drivers/sysreset/sysreset_syscon.c | 2 +- > > > > > > > > > > > > > drivers/sysreset/sysreset_watchdog.c | 40 > > > > > > > > > > > > > ++-- > > > > > > > > > > > > > drivers/watchdog/wdt-uclass.c| 8 ++ > > > > > > > > > > > > > include/sysreset.h | 10 > > > > > > > > > > > > > +++ > > > > > > > > > > > > > 9 files changed, 67 insertions(+), 13 > > > > > > > > > > > > >
Re: [PATCH 00/11] fsl_esdhc_imx: port several patches from fsl_esdhc
On 11/5/21 7:32 PM, Michael Walle wrote:
Am 2021-11-05 18:39, schrieb Sean Anderson:
This series ports some of the patches from fsl_esdhc to fsl_esdhc_imx.
Because these drivers share a common lineage, many of these patches
apply with minor changes. For each one, I have noted the originating
commit in the style of linux stable backports.
In fa33d20749 ("mmc: split fsl_esdhc driver for i.MX"), Yangbo says
For the two series processors, the eSDHCs are becoming more and more different
However, these drivers are still extremely similar; the differences
between them are not major. However, NXP has not done a good job of
porting patches which apply to both drivers. This causes the
fsl_esdhc_imx driver to rot, as the fsl_esdhc gets more general fixes.
For this reason, I think that the fsl_esdhc_imx driver should be removed
unless NXP can commit to creating series like this which port patches
which apply to both drivers.
But you are still doing patches for it? ;) Wouldn't it be easier
to just merge them again?
Well, I actually did all the work for these patches back in April but
never got around to posting them. So it's much easier for me to post
these than to merge the drivers :)
Unfortunately, there *are* feature differences that make it non-trivial
to un-split these drivers.
Funny enough, I ported some changes from the imx version to the
non-imx version.
Yeah, this is the other half of the coin; now we have to have two
versions of many patches.
So yes I agree, this situation isn't optimal. And I don't think
it makes any sense to port patches between these two. IMHO nobody
will care for both at the same time, let alone being able to test
it.
Yeah. There's a bit of an implicit promise of that from NXP, but they
haven't followed through.
--Sean
Re: [PATCH] cmd: pxe_utils: sysboot: add label override support
Hi Simon,
On 05/11/2021 03:02, Simon Glass wrote:
Hi Amjad,
On Fri, 22 Oct 2021 at 09:55, Amjad Ouled-Ameur
wrote:
This will allow consumers to choose a pxe label at runtime instead of
having to prompt the user. One good use-case for this, is choosing
whether or not to apply a dtbo depending on the hardware configuration.
e.g: for TI's AM335x EVM, it would be convenient to apply a particular
dtbo only when the J9 jumper is on PRUSS mode. To achieve this, the
pxe menu should have 2 labels, one with the dtbo and the other without,
then the "pxe_label_override" env variable should point to the label with
the dtbo at runtime only when the jumper is on PRUSS mode.
This change can be used for different use-cases and bring more
flexibilty to consumers who use sysboot/pxe_utils.
if "pxe_label_override" is set but does not exist in the pxe menu,
the code should fallback to the default label if given, and no failure
is returned but rather a warning message.
Signed-off-by: Amjad Ouled-Ameur
---
cmd/pxe_utils.c | 15 +++
1 file changed, 15 insertions(+)
Can we add this to the docs somewhere?
This would be great, I think doc/README.pxe is the best place for it.
Will send a V2 with the doc change, thank you for the suggestion.
Regards,
Amjad
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 067c24e5ff4b..b1009f9c7547 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1354,9 +1354,11 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
struct pxe_label *label;
struct list_head *pos;
struct menu *m;
+ char *label_override;
int err;
int i = 1;
char *default_num = NULL;
+ char *override_num = NULL;
/*
* Create a menu and add items for all the labels.
@@ -1367,6 +1369,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
if (!m)
return NULL;
+ label_override = env_get("pxe_label_override");
+
list_for_each(pos, >labels) {
label = list_entry(pos, struct pxe_label, list);
@@ -1375,11 +1379,22 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
menu_destroy(m);
return NULL;
}
+ if (label_override &&
+ (strcmp(label->name, label_override) == 0))
!strcmp()
+ override_num = label->num;
if (cfg->default_label &&
(strcmp(label->name, cfg->default_label) == 0))
default_num = label->num;
}
+ if (label_override) {
+ if (override_num)
+ default_num = override_num;
+ else
+ printf("Missing override pxe label: %s\n",
+ label_override);
+ }
+
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
--
2.25.1
Regards,
Simon
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
On Friday 05 November 2021 16:36:47 Tony Dinh wrote: > Hi Pali, > > On Fri, Nov 5, 2021 at 3:15 PM Pali Rohár wrote: > > > > On Friday 05 November 2021 15:07:17 Tony Dinh wrote: > > > > > Also, I have several Kirkwood boards (with various old BootROM > > > > > versions) that I can run the kwboot tests on. Will keep you posted. > > > > > > > > Ok! Do you have some Kirkwood board with PCIe slot? If yes, I would like > > > > to see dumps from config space of Kirkwood PCIe Root Port, see: > > > > https://lore.kernel.org/u-boot/20211104154921.b6zxjpczj7t6qlct@pali/ > > > > > > I have these Kirwood boards with PCI: > > > - No slot (host bus for USB 3.0): Pogoplug V4 (6192), Zyxel NSA325v2 > > > (6282). These 2 boards can be kwboot. > > > - Iomega iConnect (6281), with PCIe slot for Wifi card. This board > > > does not have kwboot booting support. > > > > What do you mean that it 'does not have kwboot booting support'? > > 88F6281 is also Kirkwood and UART booting with kwboot should work. > > Most of the Kirkwood boards do have UART booting support. However, in > my past experience, some Kirkwood boxes did not work with kwboot > booting. It was observed experimentally that certain BootROM versions > (depending on the time of manufacturing) on the 88F6281 SoC have > problems with UART booting. But we have not proven this to be the real > reason. These boards failed UART booting (the behavior is like the > UART magic string handshake never occur): > > Seagate Dockstar (all), Iomega iConnect (all), Sheevaplug (some models > probably do work), Seagate GoFlex Net (most boxes work, but a few > models don't, and they have a different BootROM version from ones that > do work). Hmm... ok. Maybe some bootrom versions have broken UART booting. During experiment with A385 I observed that it is needed to send continuous stream of boot pattern without delay, so bootrom can properly detect it and enter UART booting. But after bootrom is in UART booting mode, it responds only when do not transmitting anything for some few milliseconds. So it is needed to solve two timing issues. First with upper bound (you cannot use large delay as bootrom does not detect boot pattern) and second with lower bound (you cannot use small delay as bootrom does not answer). Plus another issue that linux kernel does provide asynchronous tty API which could tell when output buffer was transmitted via UART. If some bootrom versions are too much timing sensitive and you do not know exact characteristic of it (and also of UART HW on the host) then it could be hard or impossible to enter that UART boot mode. I'm planning to rewrite kwboot code which is sending boot pattern to be more precise on timings... So if you are interested in testing it, I could do it in a way with more configurable delays... once I would have some time for it. You could try to use tools/mrvl_uart.sh instead of kwboot. It implements also code for sending boot pattern. But it requires valid image with UART signature, it does not support on-the-fly patching like kwboot. > > > I'll take a look at your link above and get back to you about the > > > config space dumps. > > > > > > By the way, I'm starting to look at the driver/pci/pci_mvebu.c to see > > > if it can be made to work with Kirkwood SoCs. I think there are many > > > differences in the addresses and memory space. I would appreciate it > > > if you have a general assessment whether I can use that driver for > > > Kirkwood. > > > > pci_mvebu.c should work with Kirkwood SoCs and also with all these > > 32-bit Marvell SoCs: Orion, Discovery, Kirkwood, Dove, A370, AXP, A375, > > A38x and A39x. According to Functional Specifications all these SoCs > > have common PCIe register set. > > That's great to hear! > > > > > If there is any issue with it, I could try to look at it. > > At the moment, pci_mvebu.c is not included in the build for Kirkwood > boards because ./drivers/pci/Kconfig excludes it: > > config PCI_MVEBU > bool "Enable Armada XP/38x PCIe driver" > depends on ARCH_MVEBU > > When I removed the above dependency, the build had errors. Because > different soc.h and cpu.h are brought into pci_mvebu.c when > ARCH_KIRWOOD is enabled and ARCH_MVEBU is disabled. > > #include > #include So, it it needed to do some adjustment of SoC related code and defines. I think the relevant parts are mapping of mbus windows.
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
Hi Pali, On Fri, Nov 5, 2021 at 3:15 PM Pali Rohár wrote: > > On Friday 05 November 2021 15:07:17 Tony Dinh wrote: > > > > Also, I have several Kirkwood boards (with various old BootROM > > > > versions) that I can run the kwboot tests on. Will keep you posted. > > > > > > Ok! Do you have some Kirkwood board with PCIe slot? If yes, I would like > > > to see dumps from config space of Kirkwood PCIe Root Port, see: > > > https://lore.kernel.org/u-boot/20211104154921.b6zxjpczj7t6qlct@pali/ > > > > I have these Kirwood boards with PCI: > > - No slot (host bus for USB 3.0): Pogoplug V4 (6192), Zyxel NSA325v2 > > (6282). These 2 boards can be kwboot. > > - Iomega iConnect (6281), with PCIe slot for Wifi card. This board > > does not have kwboot booting support. > > What do you mean that it 'does not have kwboot booting support'? > 88F6281 is also Kirkwood and UART booting with kwboot should work. Most of the Kirkwood boards do have UART booting support. However, in my past experience, some Kirkwood boxes did not work with kwboot booting. It was observed experimentally that certain BootROM versions (depending on the time of manufacturing) on the 88F6281 SoC have problems with UART booting. But we have not proven this to be the real reason. These boards failed UART booting (the behavior is like the UART magic string handshake never occur): Seagate Dockstar (all), Iomega iConnect (all), Sheevaplug (some models probably do work), Seagate GoFlex Net (most boxes work, but a few models don't, and they have a different BootROM version from ones that do work). > > I'll take a look at your link above and get back to you about the > > config space dumps. > > > > By the way, I'm starting to look at the driver/pci/pci_mvebu.c to see > > if it can be made to work with Kirkwood SoCs. I think there are many > > differences in the addresses and memory space. I would appreciate it > > if you have a general assessment whether I can use that driver for > > Kirkwood. > > pci_mvebu.c should work with Kirkwood SoCs and also with all these > 32-bit Marvell SoCs: Orion, Discovery, Kirkwood, Dove, A370, AXP, A375, > A38x and A39x. According to Functional Specifications all these SoCs > have common PCIe register set. That's great to hear! > > If there is any issue with it, I could try to look at it. At the moment, pci_mvebu.c is not included in the build for Kirkwood boards because ./drivers/pci/Kconfig excludes it: config PCI_MVEBU bool "Enable Armada XP/38x PCIe driver" depends on ARCH_MVEBU When I removed the above dependency, the build had errors. Because different soc.h and cpu.h are brought into pci_mvebu.c when ARCH_KIRWOOD is enabled and ARCH_MVEBU is disabled. #include #include Thanks, Tony
Re: [PATCH 00/11] fsl_esdhc_imx: port several patches from fsl_esdhc
Am 2021-11-05 18:39, schrieb Sean Anderson:
This series ports some of the patches from fsl_esdhc to fsl_esdhc_imx.
Because these drivers share a common lineage, many of these patches
apply with minor changes. For each one, I have noted the originating
commit in the style of linux stable backports.
In fa33d20749 ("mmc: split fsl_esdhc driver for i.MX"), Yangbo says
For the two series processors, the eSDHCs are becoming more and more
different
However, these drivers are still extremely similar; the differences
between them are not major. However, NXP has not done a good job of
porting patches which apply to both drivers. This causes the
fsl_esdhc_imx driver to rot, as the fsl_esdhc gets more general fixes.
For this reason, I think that the fsl_esdhc_imx driver should be
removed
unless NXP can commit to creating series like this which port patches
which apply to both drivers.
But you are still doing patches for it? ;) Wouldn't it be easier
to just merge them again? Funny enough, I ported some changes from
the imx version to the non-imx version.
So yes I agree, this situation isn't optimal. And I don't think
it makes any sense to port patches between these two. IMHO nobody
will care for both at the same time, let alone being able to test
it.
-michael
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On Fri, Nov 05, 2021 at 09:38:50PM +0100, Heinrich Schuchardt wrote: > On 11/5/21 20:17, Tom Rini wrote: > > On Fri, Nov 05, 2021 at 07:37:02PM +0100, Heinrich Schuchardt wrote: > > > On 11/5/21 17:12, Simon Glass wrote: > > > > Hi, > > > > > > > > On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: > > > > > > > > > > On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: > > > > > > Hi Andre, > > > > > > > > > > > > Added Tom to Cc. > > > > > > > > > > > > On 05.11.21 11:04, Andre Przywara wrote: > > > > > > > On Thu, 4 Nov 2021 20:02:41 -0600 > > > > > > > Simon Glass wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: > > > > > > > > > > > > > > > > > > Hi Andre, > > > > > > > > > > > > > > > > > > On 05.11.21 00:11, Andre Przywara wrote: > > > > > > > > > > On Thu, 4 Nov 2021 11:37:57 +0100 > > > > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > > > > > > > Hi Stefan, > > > > > > > > > > > On 04.11.21 04:55, Samuel Holland wrote: > > > > > > > > > > > > This series hooks up the watchdog uclass to > > > > > > > > > > > > automatically register > > > > > > > > > > > > watchdog devices for use with sysreset, doing a bit of > > > > > > > > > > > > minor cleanup > > > > > > > > > > > > along the way. > > > > > > > > > > > > > > > > > > > > > > > > The goal is for this to replace the sunxi board-level > > > > > > > > > > > > non-DM reset_cpu() > > > > > > > > > > > > function. I was surprised to find that the wdt_reboot > > > > > > > > > > > > driver requires > > > > > > > > > > > > its own undocumented device tree node, which references > > > > > > > > > > > > the watchdog > > > > > > > > > > > > device by phandle. This is problematic for us, because > > > > > > > > > > > > sunxi-u-boot.dtsi > > > > > > > > > > > > file covers 20 different SoCs with varying watchdog > > > > > > > > > > > > node phandle names. > > > > > > > > > > > > So it would have required adding a -u-boot.dtsi file > > > > > > > > > > > > for each board. > > > > > > > > > > > > > > > > > > > > > > > > Hooking things up automatically makes sense to me; this > > > > > > > > > > > > is what Linux > > > > > > > > > > > > does. However, I put the code behind a new option to > > > > > > > > > > > > avoid surprises for > > > > > > > > > > > > other platforms. > > > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > - Move condition to wdt-uclass.c to fix build > > > > > > > > > > > > errors. > > > > > > > > > > > > - Include watchdog name in error message. > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > - Extend the "if SYSRESET" block to the end of > > > > > > > > > > > > the file. > > > > > > > > > > > > - Also make gpio_reboot_probe function static. > > > > > > > > > > > > - Rebase on top of 492ee6b8d0e7 (now handle all > > > > > > > > > > > > watchdogs). > > > > > > > > > > > > - Added patches 5-6 as an example of how the new > > > > > > > > > > > > option will be used. > > > > > > > > > > > > > > > > > > > > > > > > Samuel Holland (6): > > > > > > > > > > > >sysreset: Add uclass Kconfig dependency to > > > > > > > > > > > > drivers > > > > > > > > > > > >sysreset: Mark driver probe functions as static > > > > > > > > > > > >sysreset: watchdog: Move watchdog reference to > > > > > > > > > > > > plat data > > > > > > > > > > > >watchdog: Automatically register device with > > > > > > > > > > > > sysreset > > > > > > > > > > > >sunxi: Avoid duplicate reset_cpu with SYSRESET > > > > > > > > > > > > enabled > > > > > > > > > > > >sunxi: Use sysreset framework for poweroff/reset > > > > > > > > > > > > > > > > > > > > > > > > arch/arm/Kconfig | 3 +++ > > > > > > > > > > > > arch/arm/mach-sunxi/board.c | 2 ++ > > > > > > > > > > > > drivers/sysreset/Kconfig | 11 ++-- > > > > > > > > > > > > drivers/sysreset/sysreset_gpio.c | 2 +- > > > > > > > > > > > > drivers/sysreset/sysreset_resetctl.c | 2 +- > > > > > > > > > > > > drivers/sysreset/sysreset_syscon.c | 2 +- > > > > > > > > > > > > drivers/sysreset/sysreset_watchdog.c | 40 > > > > > > > > > > > > ++-- > > > > > > > > > > > > drivers/watchdog/wdt-uclass.c| 8 ++ > > > > > > > > > > > > include/sysreset.h | 10 +++ > > > > > > > > > > > > 9 files changed, 67 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > > > > > > > > > Applied to u-boot-marvell > > > > > > > > > > > > > > > > > > > > Mmmh, why u-boot-marvell, > > > > > > > > > > > > > > > > > > Because I'm handling watchdog related changed since a few > > > > > > > > > years and we > > > > > > > > > did not create a specific subsystem repo for this and I'm > > > > > > > > > usually > > > > >
[PATCH v8 1/2] net: brcm: netXtreme driver
From: Bharat Gooty
Broadcom bnxt L2 driver support. Used by the Broadcom
iproc platforms.
Signed-off-by: Bharat Gooty
Reviewed-by: Ramon Fried
Signed-off-by: Roman Bacik
---
Changes in v8:
- remove PCICFG_ME_REGISTER
Changes in v7:
- move bnxt_*.h files to drivers/net/bnxt/
- remove display_banner()
- replace pci_map_bar() with dm_pci_map_bar()
- remove changes to dev->flags_
- move PCI DID and VID definitions to include/pci_ids.h
- move bnxt_nics[] to bnxt.c
- move bnxt_alloc_mem to bnxt_read_rom_hw
- return proper error codes in bnxt_read_rom_hwaddr
Changes in v6:
- remove bnxt_eth_* env variables
- clean up include headers
Changes in v5:
- remove bnxt_env_set_ethaddr/bnxt_env_del_ethaddr methods
- add .read_rom_hwaddr = bnxt_read_rom_hwaddr
- move bnxt_bring_pci/bnxt_bring_chip to bnxt_read_rom_hwddr
- move mac copy from priv to plat to bnxt_read_rom_hwaddr
Changes in v4:
- remove static num_cards and use dev_seq(dev) instead
- add .probe
- merged probe/remove methods
- select PCI_INIT_R when BNXT_ETH is selected
Changes in v3:
- change printf to debug in display_banner
- remove get/set/print mac/speed
- remove bnxt_hwrm_set_nvmem
Changes in v2:
- rebase and remove DM_PCI dependency from BNXT_ETH
- remove tautology assignment from debug_resp()
drivers/net/Kconfig |1 +
drivers/net/Makefile|1 +
drivers/net/bnxt/Kconfig|7 +
drivers/net/bnxt/Makefile |5 +
drivers/net/bnxt/bnxt.c | 1710 +++
drivers/net/bnxt/bnxt.h | 394
drivers/net/bnxt/bnxt_dbg.h | 536 +++
drivers/net/bnxt/bnxt_hsi.h | 889 ++
drivers/net/bnxt/bnxt_ver.h | 22 +
include/pci_ids.h |3 +
10 files changed, 3568 insertions(+)
create mode 100644 drivers/net/bnxt/Kconfig
create mode 100644 drivers/net/bnxt/Makefile
create mode 100644 drivers/net/bnxt/bnxt.c
create mode 100644 drivers/net/bnxt/bnxt.h
create mode 100644 drivers/net/bnxt/bnxt_dbg.h
create mode 100644 drivers/net/bnxt/bnxt_hsi.h
create mode 100644 drivers/net/bnxt/bnxt_ver.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6c12959f3794..8dc81a3d6cf9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1,6 +1,7 @@
source "drivers/net/phy/Kconfig"
source "drivers/net/pfe_eth/Kconfig"
source "drivers/net/fsl-mc/Kconfig"
+source "drivers/net/bnxt/Kconfig"
config ETH
def_bool y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e4078d15a99f..1d9fbd6693cc 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
+obj-$(CONFIG_BNXT_ETH) += bnxt/
diff --git a/drivers/net/bnxt/Kconfig b/drivers/net/bnxt/Kconfig
new file mode 100644
index ..412ecd430335
--- /dev/null
+++ b/drivers/net/bnxt/Kconfig
@@ -0,0 +1,7 @@
+config BNXT_ETH
+ bool "BNXT PCI support"
+ depends on DM_ETH
+ select PCI_INIT_R
+ help
+ This driver implements support for bnxt pci controller
+ driver of ethernet class.
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
new file mode 100644
index ..a9d6ce00d5e0
--- /dev/null
+++ b/drivers/net/bnxt/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2019-2021 Broadcom.
+
+# Broadcom nxe Ethernet driver
+obj-y += bnxt.o
diff --git a/drivers/net/bnxt/bnxt.c b/drivers/net/bnxt/bnxt.c
new file mode 100644
index ..3d0d26fe58da
--- /dev/null
+++ b/drivers/net/bnxt/bnxt.c
@@ -0,0 +1,1710 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 Broadcom.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "bnxt.h"
+#include "bnxt_dbg.h"
+
+#define bnxt_down_chip(bp) bnxt_hwrm_run(down_chip, bp, 0)
+#define bnxt_bring_chip(bp)bnxt_hwrm_run(bring_chip, bp, 1)
+
+/* Broadcom ethernet driver PCI APIs. */
+static void bnxt_bring_pci(struct bnxt *bp)
+{
+ u16 cmd_reg = 0;
+
+ pci_read_word16(bp->pdev, PCI_VENDOR_ID, >vendor_id);
+ pci_read_word16(bp->pdev, PCI_DEVICE_ID, >device_id);
+ pci_read_word16(bp->pdev,
+ PCI_SUBSYSTEM_VENDOR_ID,
+ >subsystem_vendor);
+ pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, >subsystem_device);
+ pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg);
+ pci_read_byte(bp->pdev, PCI_INTERRUPT_LINE, >irq);
+ bp->bar0 = dm_pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
+ bp->bar1 = dm_pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_2, PCI_REGION_MEM);
+ bp->bar2 = dm_pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_4, PCI_REGION_MEM);
+ cmd_reg = bp->cmd_reg | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
+ cmd_reg |= PCI_COMMAND_INTX_DISABLE; /* disable intr */
+
Allow FIT Image Signature Verification to use RSA Public Key specified in DER Format
Hi All,
I have been able to get the FIT Image Signature verification running on a
Raspberry Pi 4 Model B by following the documentation here:
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/uImage.FIT/beaglebone_vboot.txt.
The public key, as the doc states, is stored in the Control FDT. The
signature algorithm I'm using is RSA 2048 with SHA256. I am aware the
following step:
$ mkimage -f sign.its -K bcm2711-rpi-4-pubkey.dtb -k keys -r image.fit
Will store the Public key information in the DTB as different components
split up into:
rsa,r-squaredrsa,modulusrsa,n0-inversersa,num-bits
However, I was wondering if I can directly use a certificate generated
in the following steps for FIT Image verification:
$ openssl genrsa -F4 -out keys/dev.key 2048$ openssl req -batch -new
-x509 -key keys/dev.key -out keys/dev.crt
When reading through the code, it seems that the structure
"image_sign_info" (defined in include/image.h) would allow for Public key
to be specified in DER format:
const void *key;/* Pointer to public key in DER */
So I did the following steps to convert the dev.crt Certificate to DER format:
$ openssl x509 -in ./keys/dev.crt -out dev.der -outform DER
Then I took the Hexdump of dev.der (Public Key in DER Format):
$ xxd -g 1 -u dev.der | cut -c -57 # Hexdump of the public key in DER format
And applied the following diff:
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 83f7564101..3e60dc6b50 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -499,7 +499,11 @@ int rsa_verify_hash(struct image_sign_info *info,
{
int ret = -EACCES;
- if (CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
+ // Der Format Public Key
+ char pub_key_der[] = {0x30, 0x82, 0x2F}; #
<-- Hardcoded the DER Pub Key here
+
+ info->key = pub_key_der;
+ if (CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY)) {
/* don't rely on fdt properties */
ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
However, on applying the above changes, the rsa_verify_with_pkey
function fails with error code -74.
While I am aware that the above is probably not the best way to go
about enabling FIT signature verification using a Pub Key in DER
format, it will be very helpful if I can receive pointers on how to
achieve this.
Please let me know if there is some other way in which I should be
passing my Public Key in DER format for FIT Image Signature
Verification.
[PATCH v8 2/2] board: brcm-ns3: Load netXtreme firmware
From: Bharat Gooty
Load NetXtreme firmware in board_init when BNXT_ETH is selected.
Signed-off-by: Bharat Gooty
Signed-off-by: Roman Bacik
---
(no changes since v4)
Changes in v4:
- remove bnxt commands
- load bnxt firmware in board_init
Changes in v3:
- remove commands set/get mac/speed
- add doc/bnxt.rst
board/broadcom/bcmns3/ns3.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
index 32acf367842a..88036c16c951 100644
--- a/board/broadcom/bcmns3/ns3.c
+++ b/board/broadcom/bcmns3/ns3.c
@@ -150,7 +150,10 @@ int board_init(void)
if (bl33_info->version != BL33_INFO_VERSION)
printf("*** warning: ATF BL31 and U-Boot not in sync! ***\n");
-
+#if CONFIG_IS_ENABLED(BNXT_ETH)
+ if (chimp_fastboot_optee() != 0)
+ printf("*** warning: secure chimp fastboot failed! ***\n");
+#endif
return 0;
}
--
2.17.1
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH] tools: kwboot: Always print kwboot version
It is useful to see kwboot version in the boot log output for debugging
purposes.
Signed-off-by: Pali Rohár
---
tools/kwboot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 4e4d544efd3f..d22e6ea96a5c 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1640,7 +1640,6 @@ err:
static void
kwboot_usage(FILE *stream, char *progname)
{
- fprintf(stream, "kwboot version %s\n", PLAIN_VERSION);
fprintf(stream,
"Usage: %s [OPTIONS] [-b | -D ] [-B ]
\n",
progname);
@@ -1685,6 +1684,8 @@ main(int argc, char **argv)
after_img_rsv = KWBOOT_XM_BLKSZ;
baudrate = 115200;
+ printf("kwboot version %s\n", PLAIN_VERSION);
+
kwboot_verbose = isatty(STDOUT_FILENO);
do {
--
2.20.1
[PATCH] tools: kwboot: Fix sending Kirkwood v0 images
Properly calculate and align image header size to xmodem block size.
Kirkwood v0 images do not have stored total size of header in header
structure itself like it is for v1 images. So kwbheader_size() calculates
size by traversing image structure itself. Aligning is done in kwboot by
putting zero padding bytes between the header and data part.
Signed-off-by: Pali Rohár
Tested-by: Tony Dinh
---
tools/kwboot.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index bacca1530110..4e4d544efd3f 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1073,6 +1073,14 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
int baudrate)
hdrsz = kwbheader_size(img);
+ /*
+* If header size is not aligned to xmodem block size (which applies
+* for all images in kwbimage v0 format) then we have to ensure that
+* the last xmodem block of header contains beginning of the data
+* followed by the header. So align header size to xmodem block size.
+*/
+ hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) % KWBOOT_XM_BLKSZ;
+
kwboot_printv("Waiting 2s and flushing tty\n");
sleep(2); /* flush isn't effective without it */
tcflush(tty, TCIOFLUSH);
@@ -1083,12 +1091,17 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
int baudrate)
if (rc)
return rc;
- img += hdrsz;
- size -= hdrsz;
-
- rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
- if (rc)
- return rc;
+ /*
+* If we have already sent image data as a part of the last
+* xmodem header block then we have nothing more to send.
+*/
+ if (hdrsz < size) {
+ img += hdrsz;
+ size -= hdrsz;
+ rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
+ if (rc)
+ return rc;
+ }
rc = kwboot_xm_finish(tty);
if (rc)
--
2.20.1
[PATCH 1/1] kconfig: allow defconfigs to live in board directory
This will reduce the size of the configs directory, and
make it more clear which board directory uses the defconfig
file.
Signed-off-by: Troy Kisky
---
scripts/kconfig/Makefile | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 12e525ee31..fbeb00749a 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -92,8 +92,15 @@ else
endif
endif
+%_defconfig: SHELL:=/bin/bash
%_defconfig: $(obj)/conf
- $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
+ $(Q)readarray -d '' names < <(find configs board -type f -name $@
-print0); \
+ if (test $${#names[*]} -eq 1); then \
+ $< $(silent) --defconfig="$${names[0]}" $(Kconfig); \
+ else \
+ echo "$@" not found or ambiguous error; \
+ echo "$${names[@]}"; exit 1; \
+ fi
# Added for U-Boot (backward compatibility)
%_config: %_defconfig
--
2.32.0
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
On Friday 05 November 2021 15:07:17 Tony Dinh wrote: > > > Also, I have several Kirkwood boards (with various old BootROM > > > versions) that I can run the kwboot tests on. Will keep you posted. > > > > Ok! Do you have some Kirkwood board with PCIe slot? If yes, I would like > > to see dumps from config space of Kirkwood PCIe Root Port, see: > > https://lore.kernel.org/u-boot/20211104154921.b6zxjpczj7t6qlct@pali/ > > I have these Kirwood boards with PCI: > - No slot (host bus for USB 3.0): Pogoplug V4 (6192), Zyxel NSA325v2 > (6282). These 2 boards can be kwboot. > - Iomega iConnect (6281), with PCIe slot for Wifi card. This board > does not have kwboot booting support. What do you mean that it 'does not have kwboot booting support'? 88F6281 is also Kirkwood and UART booting with kwboot should work. > I'll take a look at your link above and get back to you about the > config space dumps. > > By the way, I'm starting to look at the driver/pci/pci_mvebu.c to see > if it can be made to work with Kirkwood SoCs. I think there are many > differences in the addresses and memory space. I would appreciate it > if you have a general assessment whether I can use that driver for > Kirkwood. pci_mvebu.c should work with Kirkwood SoCs and also with all these 32-bit Marvell SoCs: Orion, Discovery, Kirkwood, Dove, A370, AXP, A375, A38x and A39x. According to Functional Specifications all these SoCs have common PCIe register set. If there is any issue with it, I could try to look at it.
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
On Fri, Nov 5, 2021 at 3:04 PM Pali Rohár wrote: > > On Friday 05 November 2021 22:09:47 Pali Rohár wrote: > > On Friday 05 November 2021 12:54:24 Roman Bacik wrote: > > > > > + pci_read_word16(bp->pdev, > > > > > + PCI_SUBSYSTEM_VENDOR_ID, > > > > > + >subsystem_vendor); > > > > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, > > > > >subsystem_device); > > > > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg); > > > > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num); > > > > > > > > PCICFG_ME_REGISTER looks like an error as there is no such PCI config > > > > space macro. What you are trying to read into pf_num? Currently I do not > > > > know what "pf" abbreviation could mean. > > > > > > PF stands for physical function and pf_num is the number of physical > > > functions configured. > > > The macro is defined in bnxt.h: > > > #define PCICFG_ME_REGISTER 0x98 > > > > pci_read_byte() reads from PCI(e) config space, which is standardized. > > Therefore only standard macro constants from include/pci.h should be > > used. Standard PCI config header is 64 byte long and after that is > > linked list of capabilities. Order of capabilities is not defined. > > Extended capabilities from linked list should be located by macro > > constants PCI_CAP_ID_*. > > > > So above register is part of some extended capability. Correctly it > > should be used some function to locate starting offset of that extended > > capability based on PCI_CAP_ID_* (see pci.h file for these functions) > > and then access that register as offset + PCI_* constant (which defined > > as relative to the start of extended capability). In case standard macro > > for this constant in pci.h is missing, it is a good idea to define it, > > or copy it from linux header file pci_regs.h (to have consistent naming > > of macros). > > Just one example how to read PCIe Link Control Register (to make it > clear what I mean): > > int ret; > u16 lnkctl; > int pci_exp_off; > pci_exp_off = dm_pci_find_capability(dev, PCI_CAP_ID_EXP); > if (!pci_exp_off) return -ENOENT; > ret = dm_pci_read_config16(dev, pci_exp_off + PCI_EXP_LNKCTL, ); > if (ret) return ret; The driver should work for 0x14e4:0x16F0 and we usually test it with this one. We will use your recommended method if needed. We will try to remove it in v8, since I do not see bp->pf_num being used. Thank you very much, Roman -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
Hi Pali,
On Fri, Nov 5, 2021 at 2:39 PM Pali Rohár wrote:
>
> Hello!
>
> On Friday 05 November 2021 14:25:14 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Fri, Nov 5, 2021 at 3:19 AM Pali Rohár wrote:
> > >
> > > On Friday 05 November 2021 09:38:28 Pali Rohár wrote:
> > > > Hello!
> > > >
> > > > On Thursday 04 November 2021 23:27:32 Tony Dinh wrote:
> > > > > Hi Marek and Pali,
> > > > >
> > > > > First off all, thanks for your hughe work on this. I have a few Armada
> > > > > 38x boards that I had quite a hard time running kwboot in the past.
> > > > > Hopefully, I will have more luck with the new kwboot.
> > > > >
> > > > > Here is a problem I've found running kwboot on the Zyxel NSA310S NAS
> > > > > (Kirkwood 6702). The target is a Pogoplug V4 (Kirkwood 6192 SoC). Same
> > > > > behavior was observed running kwboot on this Pogoplug V4 to boot the
> > > > > NSA310S target.
> > > > >
> > > > > - kwboot build version
> > > > >
> > > > > ./kwboot-2021/kwboot
> > > > > kwboot version 2022.01-rc1-00034-gbc18582a14
> > > > >
> > > > > - kwboot session log
> > > > >
> > > > > ./kwboot-2021/kwboot -t -p -B 115200 /dev/ttyUSB0 -b
> > > > > uboot.2021.07-tld-1.pogo_v4.mtd0.kwb
> > > > > Patching image boot signature to UART
> > > > > Aligning image header to Xmodem block size
> > > > > Sending boot message. Please reboot the target...\
> > > > > Waiting 2s and flushing tty
> > > > > Sending boot image header (480 bytes)...
> > > > > 26 % [
> > > > >]
> > > > > Done
> > > > >
> > > > > U-Boot 2021.04-tld-1 (Jun 10 2021 - 20:46:14 -0700)
> > > > > Pogoplug V4
> > > > >
> > > > > SoC: Kirkwood 88F6192_A1
> > > > > DRAM: 128 MiB
> > > > > NAND: 128 MiB
> > > > > MMC:
> > > > > Loading Environment from NAND... *** Warning - bad CRC, using default
> > > > > environment
> > > > > In:serial
> > > > > Out: serial
> > > > > Err: serial
> > > > > Net: eth0: ethernet-controller@72000
> > > > > 88E1116 Initialized on ethernet-controller@72000
> > > > > Hit any key to stop autoboot: 9
> > > > > 8
> > > > > 7
> > > > >
> > > > > As you can see above, it looks like the u-boot header transfer was
> > > > > completed but the u-boot image transfer did not start. Seems like
> > > > > BootROM did not recognize the header is UART.
> > > >
> > > > Yes, it looks like that kwbimage header was refused by the bootroom.
> > >
> > > Tony, could you try following patch?
> > >
> > > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > > index bacca1530110..2470906a38d1 100644
> > > --- a/tools/kwboot.c
> > > +++ b/tools/kwboot.c
> > > @@ -1072,6 +1072,7 @@ kwboot_xmodem(int tty, const void *_img, size_t
> > > size, int baudrate)
> > > size_t hdrsz;
> > >
> > > hdrsz = kwbheader_size(img);
> > > + hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) %
> > > KWBOOT_XM_BLKSZ;
> > >
> > > kwboot_printv("Waiting 2s and flushing tty\n");
> > > sleep(2); /* flush isn't effective without it */
> > > @@ -1083,12 +1084,13 @@ kwboot_xmodem(int tty, const void *_img, size_t
> > > size, int baudrate)
> > > if (rc)
> > > return rc;
> > >
> > > - img += hdrsz;
> > > - size -= hdrsz;
> > > -
> > > - rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
> > > - if (rc)
> > > - return rc;
> > > + if (hdrsz < size) {
> > > + img += hdrsz;
> > > + size -= hdrsz;
> > > + rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
> > > + if (rc)
> > > + return rc;
> > > + }
> > >
> > > rc = kwboot_xm_finish(tty);
> > > if (rc)
> > >
> >
> > Thanks, the patch works great! Here is the log.
>
> Perfect! I did not think that I will detect and fix this issue at the
> first shot.
>
> I will send this patch with proper commit message.
>
> > ./kwboot-2021/kwboot
> > kwboot version 2022.01-rc1-00041-g2a5ad542e6-dirty
> >
> > ./kwboot-2021/kwboot -t -B 115200 /dev/ttyUSB0 -b
> > uboot.2021.07-tld-1.pogo_v4.mtd0.kwb
> > Patching image boot signature to UART
> > Aligning image header to Xmodem block size
> > Sending boot message. Please reboot the target...\
> > Waiting 2s and flushing tty
> > Sending boot image header (512 bytes)...
> > 25 % [
> > ]
> > Done
> > Sending boot image data (534200 bytes)...
> > 0 %
> > [..]
> >
> > 98 % [
> > ]
> > Done
> > Finishing transfer
> > [Type Ctrl-\ + c to quit]
> >
> >
> > U-Boot 2021.07-tld-1 (Nov 02 2021 - 19:48:03 -0700)
> > Pogoplug V4
> > SoC: Kirkwood 88F6192_A1
> > Model: Pogoplug v4
> > DRAM: 128 MiB
> > NAND: 128 MiB
> > MMC: mvsdio@9: 0
> > Loading Environment from NAND... *** Warning - bad CRC, using default
> > environment
> > In:
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
On Friday 05 November 2021 22:09:47 Pali Rohár wrote: > On Friday 05 November 2021 12:54:24 Roman Bacik wrote: > > > > + pci_read_word16(bp->pdev, > > > > + PCI_SUBSYSTEM_VENDOR_ID, > > > > + >subsystem_vendor); > > > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, > > > >subsystem_device); > > > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg); > > > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num); > > > > > > PCICFG_ME_REGISTER looks like an error as there is no such PCI config > > > space macro. What you are trying to read into pf_num? Currently I do not > > > know what "pf" abbreviation could mean. > > > > PF stands for physical function and pf_num is the number of physical > > functions configured. > > The macro is defined in bnxt.h: > > #define PCICFG_ME_REGISTER 0x98 > > pci_read_byte() reads from PCI(e) config space, which is standardized. > Therefore only standard macro constants from include/pci.h should be > used. Standard PCI config header is 64 byte long and after that is > linked list of capabilities. Order of capabilities is not defined. > Extended capabilities from linked list should be located by macro > constants PCI_CAP_ID_*. > > So above register is part of some extended capability. Correctly it > should be used some function to locate starting offset of that extended > capability based on PCI_CAP_ID_* (see pci.h file for these functions) > and then access that register as offset + PCI_* constant (which defined > as relative to the start of extended capability). In case standard macro > for this constant in pci.h is missing, it is a good idea to define it, > or copy it from linux header file pci_regs.h (to have consistent naming > of macros). Just one example how to read PCIe Link Control Register (to make it clear what I mean): int ret; u16 lnkctl; int pci_exp_off; pci_exp_off = dm_pci_find_capability(dev, PCI_CAP_ID_EXP); if (!pci_exp_off) return -ENOENT; ret = dm_pci_read_config16(dev, pci_exp_off + PCI_EXP_LNKCTL, ); if (ret) return ret;
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
On Friday 05 November 2021 14:41:44 Roman Bacik wrote: > On Fri, Nov 5, 2021 at 2:29 PM Pali Rohár wrote: > > > > On Friday 05 November 2021 14:19:46 Roman Bacik wrote: > > > Hi Pali, > > > > > > On Fri, Nov 5, 2021 at 2:09 PM Pali Rohár wrote: > > > > > > > > On Friday 05 November 2021 12:54:24 Roman Bacik wrote: > > > > > > > + pci_read_word16(bp->pdev, > > > > > > > + PCI_SUBSYSTEM_VENDOR_ID, > > > > > > > + >subsystem_vendor); > > > > > > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, > > > > > > >subsystem_device); > > > > > > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg); > > > > > > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num); > > > > > > > > > > > > PCICFG_ME_REGISTER looks like an error as there is no such PCI > > > > > > config > > > > > > space macro. What you are trying to read into pf_num? Currently I > > > > > > do not > > > > > > know what "pf" abbreviation could mean. > > > > > > > > > > PF stands for physical function and pf_num is the number of physical > > > > > functions configured. > > > > > The macro is defined in bnxt.h: > > > > > #define PCICFG_ME_REGISTER 0x98 > > > > > > > > pci_read_byte() reads from PCI(e) config space, which is standardized. > > > > Therefore only standard macro constants from include/pci.h should be > > > > used. Standard PCI config header is 64 byte long and after that is > > > > linked list of capabilities. Order of capabilities is not defined. > > > > Extended capabilities from linked list should be located by macro > > > > constants PCI_CAP_ID_*. > > > > > > > > So above register is part of some extended capability. Correctly it > > > > should be used some function to locate starting offset of that extended > > > > capability based on PCI_CAP_ID_* (see pci.h file for these functions) > > > > and then access that register as offset + PCI_* constant (which defined > > > > as relative to the start of extended capability). In case standard macro > > > > for this constant in pci.h is missing, it is a good idea to define it, > > > > or copy it from linux header file pci_regs.h (to have consistent naming > > > > of macros). > > > > > > > > Could you provide output of 'lspci -nn -vv' from linux for this card? > > > > Or 'pci display.b ?.?.? 0 0x1000' dump from U-Boot? > > > > This could help me to under what kind of register that 0x98 is. > > > > > > > > I can write this part of code, no problem, just I need to see layout of > > > > config space of that card. > > > > > > Here it is: > > > > > > u-boot> pci display.b ?.?.? 0 1000 > > > > Hello! '?.?.?' is placeholder for bus-device-function PCI address of > > card. So should replace it by correct address at which is that card. > > (What you have sent is dump of PCIe Root Port, probably from 0.0.0) > > Oh right, I thought it would print all. Here is Linux output: > > 0008:00:00.0 PCI bridge [0604]: Broadcom Limited Device [14e4:d750] > 0008:01:00.0 Ethernet controller [0200]: Broadcom Limited Device [14e4:d804] > 0008:01:00.1 Ethernet controller [0200]: Broadcom Limited Device [14e4:d804] > 0008:01:00.2 Ethernet controller [0200]: Broadcom Limited Device [14e4:d804] > 0008:01:00.3 Ethernet controller [0200]: Broadcom Limited Device [14e4:d804] Hmmm? There is no ethernet controller with id 0x14e4:0x16F0 for which you have wrote this U-Boot driver.
Re: [PATCH 3/4] gpio: sunxi: Implement .set_flags
On 11/5/21 9:43 AM, Heinrich Schuchardt wrote:
> On 10/21/21 06:52, Samuel Holland wrote:
>> This, along with gpio_flags_xlate(), allows the GPIO driver to handle
>> pull-up/down flags provided by consumer drivers or in the device tree.
>>
>> Signed-off-by: Samuel Holland
>> Reviewed-by: Simon Glass
>> ---
>>
>> drivers/gpio/sunxi_gpio.c | 62 +--
>> 1 file changed, 27 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
>> index cdbc40d48f..92fee0118d 100644
>> --- a/drivers/gpio/sunxi_gpio.c
>> +++ b/drivers/gpio/sunxi_gpio.c
>> @@ -139,27 +139,6 @@ int sunxi_name_to_gpio(const char *name)
>> return ret ? ret : gpio;
>> }
>> -static int sunxi_gpio_direction_input(struct udevice *dev, unsigned
>> offset)
>> -{
>> - struct sunxi_gpio_plat *plat = dev_get_plat(dev);
>> -
>> - sunxi_gpio_set_cfgbank(plat->regs, offset, SUNXI_GPIO_INPUT);
>> -
>> - return 0;
>> -}
>> -
>> -static int sunxi_gpio_direction_output(struct udevice *dev, unsigned
>> offset,
>> - int value)
>> -{
>> - struct sunxi_gpio_plat *plat = dev_get_plat(dev);
>> - u32 num = GPIO_NUM(offset);
>> -
>> - sunxi_gpio_set_cfgbank(plat->regs, offset, SUNXI_GPIO_OUTPUT);
>> - clrsetbits_le32(>regs->dat, 1 << num, value ? (1 << num) : 0);
>> -
>> - return 0;
>> -}
>> -
>> static int sunxi_gpio_get_value(struct udevice *dev, unsigned offset)
>> {
>> struct sunxi_gpio_plat *plat = dev_get_plat(dev);
>> @@ -172,16 +151,6 @@ static int sunxi_gpio_get_value(struct udevice
>> *dev, unsigned offset)
>> return dat & 0x1;
>> }
>> -static int sunxi_gpio_set_value(struct udevice *dev, unsigned offset,
>> - int value)
>> -{
>> - struct sunxi_gpio_plat *plat = dev_get_plat(dev);
>> - u32 num = GPIO_NUM(offset);
>> -
>> - clrsetbits_le32(>regs->dat, 1 << num, value ? (1 << num) : 0);
>> - return 0;
>> -}
>> -
>> static int sunxi_gpio_get_function(struct udevice *dev, unsigned
>> offset)
>> {
>> struct sunxi_gpio_plat *plat = dev_get_plat(dev);
>> @@ -205,18 +174,41 @@ static int sunxi_gpio_xlate(struct udevice *dev,
>> struct gpio_desc *desc,
>> if (ret)
>> return ret;
>> desc->offset = args->args[1];
>> - desc->flags = args->args[2] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW
>> : 0;
>> + desc->flags = gpio_flags_xlate(args->args[2]);
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_gpio_set_flags(struct udevice *dev, unsigned int
>> offset,
>> + ulong flags)
>> +{
>> + struct sunxi_gpio_plat *plat = dev_get_plat(dev);
>> +
>> + if (flags & GPIOD_IS_OUT) {
>> + u32 value = !!(flags & GPIOD_IS_OUT_ACTIVE);
>> + u32 num = GPIO_NUM(offset);
>> +
>> + clrsetbits_le32(>regs->dat, 1 << num, value << num);
>> + sunxi_gpio_set_cfgbank(plat->regs, offset, SUNXI_GPIO_OUTPUT);
>> + } else if (flags & GPIOD_IS_IN) {
>> + u32 pull = 0;
>> +
>> + if (flags & GPIOD_PULL_UP)
>> + pull = 1;
>> + else if (flags & GPIOD_PULL_DOWN)
>> + pull = 2;
>> + sunxi_gpio_set_pull_bank(plat->regs, offset, pull);
>> + sunxi_gpio_set_cfgbank(plat->regs, offset, SUNXI_GPIO_INPUT);
>> + }
>> return 0;
>> }
>> static const struct dm_gpio_ops gpio_sunxi_ops = {
>> - .direction_input = sunxi_gpio_direction_input,
>> - .direction_output = sunxi_gpio_direction_output,
>
> Removing these operations is not related to your commit message.
>
> dm_gpio_set_value() seems to be using them.
It does not use any of these operations when set_flags is provided. The
same applies to _dm_gpio_set_flags().
asm-generic/gpio.h says about set_flags:
> This method is required and should be implemented by new drivers. At
> some point, it will supersede direction_input() and
> direction_output(), which wil be removed.
So I believe it is intended to replace the other three operations.
Regards,
Samuel
>> .get_value = sunxi_gpio_get_value,
>> - .set_value = sunxi_gpio_set_value,
>
> Same here.
>
> Best regards
>
> Heinrich
>
>> .get_function = sunxi_gpio_get_function,
>> .xlate = sunxi_gpio_xlate,
>> + .set_flags = sunxi_gpio_set_flags,
>> };
>> /**
>>
>
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
On Fri, Nov 5, 2021 at 2:29 PM Pali Rohár wrote: > > On Friday 05 November 2021 14:19:46 Roman Bacik wrote: > > Hi Pali, > > > > On Fri, Nov 5, 2021 at 2:09 PM Pali Rohár wrote: > > > > > > On Friday 05 November 2021 12:54:24 Roman Bacik wrote: > > > > > > + pci_read_word16(bp->pdev, > > > > > > + PCI_SUBSYSTEM_VENDOR_ID, > > > > > > + >subsystem_vendor); > > > > > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, > > > > > >subsystem_device); > > > > > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg); > > > > > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num); > > > > > > > > > > PCICFG_ME_REGISTER looks like an error as there is no such PCI config > > > > > space macro. What you are trying to read into pf_num? Currently I do > > > > > not > > > > > know what "pf" abbreviation could mean. > > > > > > > > PF stands for physical function and pf_num is the number of physical > > > > functions configured. > > > > The macro is defined in bnxt.h: > > > > #define PCICFG_ME_REGISTER 0x98 > > > > > > pci_read_byte() reads from PCI(e) config space, which is standardized. > > > Therefore only standard macro constants from include/pci.h should be > > > used. Standard PCI config header is 64 byte long and after that is > > > linked list of capabilities. Order of capabilities is not defined. > > > Extended capabilities from linked list should be located by macro > > > constants PCI_CAP_ID_*. > > > > > > So above register is part of some extended capability. Correctly it > > > should be used some function to locate starting offset of that extended > > > capability based on PCI_CAP_ID_* (see pci.h file for these functions) > > > and then access that register as offset + PCI_* constant (which defined > > > as relative to the start of extended capability). In case standard macro > > > for this constant in pci.h is missing, it is a good idea to define it, > > > or copy it from linux header file pci_regs.h (to have consistent naming > > > of macros). > > > > > > Could you provide output of 'lspci -nn -vv' from linux for this card? > > > Or 'pci display.b ?.?.? 0 0x1000' dump from U-Boot? > > > This could help me to under what kind of register that 0x98 is. > > > > > > I can write this part of code, no problem, just I need to see layout of > > > config space of that card. > > > > Here it is: > > > > u-boot> pci display.b ?.?.? 0 1000 > > Hello! '?.?.?' is placeholder for bus-device-function PCI address of > card. So should replace it by correct address at which is that card. > (What you have sent is dump of PCIe Root Port, probably from 0.0.0) Oh right, I thought it would print all. Here is Linux output: 0008:00:00.0 PCI bridge [0604]: Broadcom Limited Device [14e4:d750] (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [48] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME- Capabilities: [ac] Express (v2) Root Port (Slot-), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+ MaxPayload 512 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <2us ClockPM+ Surprise- LLActRep- BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported ARIFwd- AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd- AtomicOpsCtl: ReqEn- EgressBlck- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB,
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
Hello!
On Friday 05 November 2021 14:25:14 Tony Dinh wrote:
> Hi Pali,
>
> On Fri, Nov 5, 2021 at 3:19 AM Pali Rohár wrote:
> >
> > On Friday 05 November 2021 09:38:28 Pali Rohár wrote:
> > > Hello!
> > >
> > > On Thursday 04 November 2021 23:27:32 Tony Dinh wrote:
> > > > Hi Marek and Pali,
> > > >
> > > > First off all, thanks for your hughe work on this. I have a few Armada
> > > > 38x boards that I had quite a hard time running kwboot in the past.
> > > > Hopefully, I will have more luck with the new kwboot.
> > > >
> > > > Here is a problem I've found running kwboot on the Zyxel NSA310S NAS
> > > > (Kirkwood 6702). The target is a Pogoplug V4 (Kirkwood 6192 SoC). Same
> > > > behavior was observed running kwboot on this Pogoplug V4 to boot the
> > > > NSA310S target.
> > > >
> > > > - kwboot build version
> > > >
> > > > ./kwboot-2021/kwboot
> > > > kwboot version 2022.01-rc1-00034-gbc18582a14
> > > >
> > > > - kwboot session log
> > > >
> > > > ./kwboot-2021/kwboot -t -p -B 115200 /dev/ttyUSB0 -b
> > > > uboot.2021.07-tld-1.pogo_v4.mtd0.kwb
> > > > Patching image boot signature to UART
> > > > Aligning image header to Xmodem block size
> > > > Sending boot message. Please reboot the target...\
> > > > Waiting 2s and flushing tty
> > > > Sending boot image header (480 bytes)...
> > > > 26 % [
> > > > ]
> > > > Done
> > > >
> > > > U-Boot 2021.04-tld-1 (Jun 10 2021 - 20:46:14 -0700)
> > > > Pogoplug V4
> > > >
> > > > SoC: Kirkwood 88F6192_A1
> > > > DRAM: 128 MiB
> > > > NAND: 128 MiB
> > > > MMC:
> > > > Loading Environment from NAND... *** Warning - bad CRC, using default
> > > > environment
> > > > In:serial
> > > > Out: serial
> > > > Err: serial
> > > > Net: eth0: ethernet-controller@72000
> > > > 88E1116 Initialized on ethernet-controller@72000
> > > > Hit any key to stop autoboot: 9
> > > > 8
> > > > 7
> > > >
> > > > As you can see above, it looks like the u-boot header transfer was
> > > > completed but the u-boot image transfer did not start. Seems like
> > > > BootROM did not recognize the header is UART.
> > >
> > > Yes, it looks like that kwbimage header was refused by the bootroom.
> >
> > Tony, could you try following patch?
> >
> > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > index bacca1530110..2470906a38d1 100644
> > --- a/tools/kwboot.c
> > +++ b/tools/kwboot.c
> > @@ -1072,6 +1072,7 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
> > int baudrate)
> > size_t hdrsz;
> >
> > hdrsz = kwbheader_size(img);
> > + hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) %
> > KWBOOT_XM_BLKSZ;
> >
> > kwboot_printv("Waiting 2s and flushing tty\n");
> > sleep(2); /* flush isn't effective without it */
> > @@ -1083,12 +1084,13 @@ kwboot_xmodem(int tty, const void *_img, size_t
> > size, int baudrate)
> > if (rc)
> > return rc;
> >
> > - img += hdrsz;
> > - size -= hdrsz;
> > -
> > - rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
> > - if (rc)
> > - return rc;
> > + if (hdrsz < size) {
> > + img += hdrsz;
> > + size -= hdrsz;
> > + rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
> > + if (rc)
> > + return rc;
> > + }
> >
> > rc = kwboot_xm_finish(tty);
> > if (rc)
> >
>
> Thanks, the patch works great! Here is the log.
Perfect! I did not think that I will detect and fix this issue at the
first shot.
I will send this patch with proper commit message.
> ./kwboot-2021/kwboot
> kwboot version 2022.01-rc1-00041-g2a5ad542e6-dirty
>
> ./kwboot-2021/kwboot -t -B 115200 /dev/ttyUSB0 -b
> uboot.2021.07-tld-1.pogo_v4.mtd0.kwb
> Patching image boot signature to UART
> Aligning image header to Xmodem block size
> Sending boot message. Please reboot the target...\
> Waiting 2s and flushing tty
> Sending boot image header (512 bytes)...
> 25 % [ ]
> Done
> Sending boot image data (534200 bytes)...
> 0 % [..]
>
> 98 % [ ]
> Done
> Finishing transfer
> [Type Ctrl-\ + c to quit]
>
>
> U-Boot 2021.07-tld-1 (Nov 02 2021 - 19:48:03 -0700)
> Pogoplug V4
> SoC: Kirkwood 88F6192_A1
> Model: Pogoplug v4
> DRAM: 128 MiB
> NAND: 128 MiB
> MMC: mvsdio@9: 0
> Loading Environment from NAND... *** Warning - bad CRC, using default
> environment
> In:serial
> Out: serial
> Err: serial
> Net:
> Warning: ethernet-controller@72000 (eth0) using random MAC address -
> 12:1c:5b:05:ed:15
> eth0: ethernet-controller@72000
> Hit any key to stop autoboot: 0
> Pogo_V4>
>
> Also, I have several Kirkwood boards (with various old BootROM
> versions) that I can run the kwboot tests on. Will keep you
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
On Friday 05 November 2021 14:19:46 Roman Bacik wrote: > Hi Pali, > > On Fri, Nov 5, 2021 at 2:09 PM Pali Rohár wrote: > > > > On Friday 05 November 2021 12:54:24 Roman Bacik wrote: > > > > > + pci_read_word16(bp->pdev, > > > > > + PCI_SUBSYSTEM_VENDOR_ID, > > > > > + >subsystem_vendor); > > > > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, > > > > >subsystem_device); > > > > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg); > > > > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num); > > > > > > > > PCICFG_ME_REGISTER looks like an error as there is no such PCI config > > > > space macro. What you are trying to read into pf_num? Currently I do not > > > > know what "pf" abbreviation could mean. > > > > > > PF stands for physical function and pf_num is the number of physical > > > functions configured. > > > The macro is defined in bnxt.h: > > > #define PCICFG_ME_REGISTER 0x98 > > > > pci_read_byte() reads from PCI(e) config space, which is standardized. > > Therefore only standard macro constants from include/pci.h should be > > used. Standard PCI config header is 64 byte long and after that is > > linked list of capabilities. Order of capabilities is not defined. > > Extended capabilities from linked list should be located by macro > > constants PCI_CAP_ID_*. > > > > So above register is part of some extended capability. Correctly it > > should be used some function to locate starting offset of that extended > > capability based on PCI_CAP_ID_* (see pci.h file for these functions) > > and then access that register as offset + PCI_* constant (which defined > > as relative to the start of extended capability). In case standard macro > > for this constant in pci.h is missing, it is a good idea to define it, > > or copy it from linux header file pci_regs.h (to have consistent naming > > of macros). > > > > Could you provide output of 'lspci -nn -vv' from linux for this card? > > Or 'pci display.b ?.?.? 0 0x1000' dump from U-Boot? > > This could help me to under what kind of register that 0x98 is. > > > > I can write this part of code, no problem, just I need to see layout of > > config space of that card. > > Here it is: > > u-boot> pci display.b ?.?.? 0 1000 Hello! '?.?.?' is placeholder for bus-device-function PCI address of card. So should replace it by correct address at which is that card. (What you have sent is dump of PCIe Root Port, probably from 0.0.0)
Re: kwboot: Testing latest kwboot with Kirkwood SoC boards
Hi Pali,
On Fri, Nov 5, 2021 at 3:19 AM Pali Rohár wrote:
>
> On Friday 05 November 2021 09:38:28 Pali Rohár wrote:
> > Hello!
> >
> > On Thursday 04 November 2021 23:27:32 Tony Dinh wrote:
> > > Hi Marek and Pali,
> > >
> > > First off all, thanks for your hughe work on this. I have a few Armada
> > > 38x boards that I had quite a hard time running kwboot in the past.
> > > Hopefully, I will have more luck with the new kwboot.
> > >
> > > Here is a problem I've found running kwboot on the Zyxel NSA310S NAS
> > > (Kirkwood 6702). The target is a Pogoplug V4 (Kirkwood 6192 SoC). Same
> > > behavior was observed running kwboot on this Pogoplug V4 to boot the
> > > NSA310S target.
> > >
> > > - kwboot build version
> > >
> > > ./kwboot-2021/kwboot
> > > kwboot version 2022.01-rc1-00034-gbc18582a14
> > >
> > > - kwboot session log
> > >
> > > ./kwboot-2021/kwboot -t -p -B 115200 /dev/ttyUSB0 -b
> > > uboot.2021.07-tld-1.pogo_v4.mtd0.kwb
> > > Patching image boot signature to UART
> > > Aligning image header to Xmodem block size
> > > Sending boot message. Please reboot the target...\
> > > Waiting 2s and flushing tty
> > > Sending boot image header (480 bytes)...
> > > 26 % [
> > >]
> > > Done
> > >
> > > U-Boot 2021.04-tld-1 (Jun 10 2021 - 20:46:14 -0700)
> > > Pogoplug V4
> > >
> > > SoC: Kirkwood 88F6192_A1
> > > DRAM: 128 MiB
> > > NAND: 128 MiB
> > > MMC:
> > > Loading Environment from NAND... *** Warning - bad CRC, using default
> > > environment
> > > In:serial
> > > Out: serial
> > > Err: serial
> > > Net: eth0: ethernet-controller@72000
> > > 88E1116 Initialized on ethernet-controller@72000
> > > Hit any key to stop autoboot: 9
> > > 8
> > > 7
> > >
> > > As you can see above, it looks like the u-boot header transfer was
> > > completed but the u-boot image transfer did not start. Seems like
> > > BootROM did not recognize the header is UART.
> >
> > Yes, it looks like that kwbimage header was refused by the bootroom.
>
> Tony, could you try following patch?
>
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index bacca1530110..2470906a38d1 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -1072,6 +1072,7 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
> int baudrate)
> size_t hdrsz;
>
> hdrsz = kwbheader_size(img);
> + hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) %
> KWBOOT_XM_BLKSZ;
>
> kwboot_printv("Waiting 2s and flushing tty\n");
> sleep(2); /* flush isn't effective without it */
> @@ -1083,12 +1084,13 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
> int baudrate)
> if (rc)
> return rc;
>
> - img += hdrsz;
> - size -= hdrsz;
> -
> - rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
> - if (rc)
> - return rc;
> + if (hdrsz < size) {
> + img += hdrsz;
> + size -= hdrsz;
> + rc = kwboot_xmodem_one(tty, , 0, img, size, 0);
> + if (rc)
> + return rc;
> + }
>
> rc = kwboot_xm_finish(tty);
> if (rc)
>
Thanks, the patch works great! Here is the log.
./kwboot-2021/kwboot
kwboot version 2022.01-rc1-00041-g2a5ad542e6-dirty
./kwboot-2021/kwboot -t -B 115200 /dev/ttyUSB0 -b
uboot.2021.07-tld-1.pogo_v4.mtd0.kwb
Patching image boot signature to UART
Aligning image header to Xmodem block size
Sending boot message. Please reboot the target...\
Waiting 2s and flushing tty
Sending boot image header (512 bytes)...
25 % [ ]
Done
Sending boot image data (534200 bytes)...
0 % [..]
98 % [ ]
Done
Finishing transfer
[Type Ctrl-\ + c to quit]
U-Boot 2021.07-tld-1 (Nov 02 2021 - 19:48:03 -0700)
Pogoplug V4
SoC: Kirkwood 88F6192_A1
Model: Pogoplug v4
DRAM: 128 MiB
NAND: 128 MiB
MMC: mvsdio@9: 0
Loading Environment from NAND... *** Warning - bad CRC, using default
environment
In:serial
Out: serial
Err: serial
Net:
Warning: ethernet-controller@72000 (eth0) using random MAC address -
12:1c:5b:05:ed:15
eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4>
Also, I have several Kirkwood boards (with various old BootROM
versions) that I can run the kwboot tests on. Will keep you posted.
Thanks,
Tony
> > Do you have some older U-Boot binary in .kwb format which you can
> > successfully boot? Or are you able to boot that U-Boot binary via some
> > older version of kwboot?
> >
> > I would like to inspect some working setup, so need some U-Boot binary
> > which can be successfully transferred.
> >
> > > The Pogoplug V4
> > > continued to boot with the image on NAND (U-Boot 2021.04-tld-1). So
> > > kwboot_xm_finish() was never executed. At this point we
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
Hi Pali, On Fri, Nov 5, 2021 at 2:09 PM Pali Rohár wrote: > > On Friday 05 November 2021 12:54:24 Roman Bacik wrote: > > > > + pci_read_word16(bp->pdev, > > > > + PCI_SUBSYSTEM_VENDOR_ID, > > > > + >subsystem_vendor); > > > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, > > > >subsystem_device); > > > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg); > > > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num); > > > > > > PCICFG_ME_REGISTER looks like an error as there is no such PCI config > > > space macro. What you are trying to read into pf_num? Currently I do not > > > know what "pf" abbreviation could mean. > > > > PF stands for physical function and pf_num is the number of physical > > functions configured. > > The macro is defined in bnxt.h: > > #define PCICFG_ME_REGISTER 0x98 > > pci_read_byte() reads from PCI(e) config space, which is standardized. > Therefore only standard macro constants from include/pci.h should be > used. Standard PCI config header is 64 byte long and after that is > linked list of capabilities. Order of capabilities is not defined. > Extended capabilities from linked list should be located by macro > constants PCI_CAP_ID_*. > > So above register is part of some extended capability. Correctly it > should be used some function to locate starting offset of that extended > capability based on PCI_CAP_ID_* (see pci.h file for these functions) > and then access that register as offset + PCI_* constant (which defined > as relative to the start of extended capability). In case standard macro > for this constant in pci.h is missing, it is a good idea to define it, > or copy it from linux header file pci_regs.h (to have consistent naming > of macros). > > Could you provide output of 'lspci -nn -vv' from linux for this card? > Or 'pci display.b ?.?.? 0 0x1000' dump from U-Boot? > This could help me to under what kind of register that 0x98 is. > > I can write this part of code, no problem, just I need to see layout of > config space of that card. Here it is: u-boot> pci display.b ?.?.? 0 1000 : e4 14 50 d7 06 00 10 00 00 00 04 06 08 00 01 00 0010: 00 00 00 00 00 00 00 00 00 01 01 00 00 00 00 00 0020: 00 10 50 10 01 10 01 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 48 00 00 00 00 00 00 00 00 00 00 00 0040: 00 00 00 00 00 00 00 00 01 ac 03 c8 08 20 00 00 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 10 00 42 00 00b0: 00 80 00 00 10 2c 10 00 03 5d 65 00 00 00 03 11 00c0: 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00d0: 1f 08 00 00 00 00 00 00 0e 00 00 00 02 00 00 00 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180: 0b 00 01 24 00 00 80 02 00 00 00 00 00 00 00 00 0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0310: 00 00 00 00 00 00 00 00 00 00 00
Re: [PATCH v3 0/3] fpga: zynqmp: Adding support of loading authenticated images
Hello Michal, On Wed, Nov 3, 2021 at 1:45 PM Michal Simek wrote: > > > > On 11/2/21 14:49, Oleksandr Suvorov wrote: > > > > This patchset introduces support for the authenticated FPGA images > > on ZynqMP boards, besides that introducing common way to pass the > > compatible property to any fpga driver. > > > > It bases on the initial work by Jorge Ramirez-Ortiz > > https://patchwork.ozlabs.org/project/uboot/patch/20211015091506.2602-1-jo...@foundries.io/ > > https://patchwork.ozlabs.org/project/uboot/patch/20211005111324.19749-3-jo...@foundries.io/ > > > > Changes in v3: > > - remove the patch which introduced CMD_SPL_FPGA_LOAD_SECURE. > > - fix mixing definitions/declarations. > > - replace strcmp() calls with more secure strncmp(). > > - document the "u-boot,zynqmp-fpga-ddrauth" compatible string. > > - fix code style by check-patch recommendations. > > > > Changes in v2: > > - add function fit_fpga_load() to simplify calls of fpga_load() > >from contexts without a compatible attribute. > > - move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c > > - prepare for passing a "compatible" FDT property to any fpga driver. > > > > Oleksandr Suvorov (3): > >fpga: add option for loading FPGA secure bitstreams > >fpga: add fit_fpga_load function > >fpga: zynqmp: support loading authenticated images > > > > cmd/Kconfig | 3 ++- > > common/Kconfig.boot | 4 +-- > > common/spl/spl_fit.c | 6 ++--- > > doc/uImage.FIT/source_file_format.txt | 5 +++- > > drivers/fpga/Kconfig | 14 ++ > > drivers/fpga/fpga.c | 37 +-- > > drivers/fpga/xilinx.c | 2 +- > > drivers/fpga/zynqmppl.c | 25 -- > > include/fpga.h| 4 +++ > > 9 files changed, 81 insertions(+), 19 deletions(-) > > > > Applied. Thanks! Unfortunately (my bad) we tested not the latest variant of the patchset. And this one, applied, has a bug. If you can rewrite a tree of a branch where the patchset is applied, please, remove it and I'll send the next version, fixed. Otherwise, I'll send new patches with a fix for the bug. Both variants are ready. Sorry for that :( -- Best regards, Oleksandr Suvorov Software Engineer T: +380 63 8489656 E: oleksandr.suvo...@foundries.io W: www.foundries.io
Re: [PATCH v6 1/2] net: brcm: netXtreme driver
On Friday 05 November 2021 12:54:24 Roman Bacik wrote:
> > > + pci_read_word16(bp->pdev,
> > > + PCI_SUBSYSTEM_VENDOR_ID,
> > > + >subsystem_vendor);
> > > + pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID,
> > >subsystem_device);
> > > + pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg);
> > > + pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num);
> >
> > PCICFG_ME_REGISTER looks like an error as there is no such PCI config
> > space macro. What you are trying to read into pf_num? Currently I do not
> > know what "pf" abbreviation could mean.
>
> PF stands for physical function and pf_num is the number of physical
> functions configured.
> The macro is defined in bnxt.h:
> #define PCICFG_ME_REGISTER 0x98
pci_read_byte() reads from PCI(e) config space, which is standardized.
Therefore only standard macro constants from include/pci.h should be
used. Standard PCI config header is 64 byte long and after that is
linked list of capabilities. Order of capabilities is not defined.
Extended capabilities from linked list should be located by macro
constants PCI_CAP_ID_*.
So above register is part of some extended capability. Correctly it
should be used some function to locate starting offset of that extended
capability based on PCI_CAP_ID_* (see pci.h file for these functions)
and then access that register as offset + PCI_* constant (which defined
as relative to the start of extended capability). In case standard macro
for this constant in pci.h is missing, it is a good idea to define it,
or copy it from linux header file pci_regs.h (to have consistent naming
of macros).
Could you provide output of 'lspci -nn -vv' from linux for this card?
Or 'pci display.b ?.?.? 0 0x1000' dump from U-Boot?
This could help me to under what kind of register that 0x98 is.
I can write this part of code, no problem, just I need to see layout of
config space of that card.
> >
> > > + pci_read_byte(bp->pdev, PCI_INTERRUPT_LINE, >irq);
> > > + bp->bar0 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_0,
> > PCI_REGION_MEM);
> > > + bp->bar1 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_2,
> > PCI_REGION_MEM);
> > > + bp->bar2 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_4,
> > PCI_REGION_MEM);
> >
> > pci_map_bar() is obsolete and should not be used in a new code. Please
> > switch to DM and use new DM API.
>
> We will replace with dm_pci_map_bar().
>
> >
> > Check that you can compile driver without CONFIG_DM_PCI_COMPAT
> > option.
> > I think it should throw compile error on usage of this function.
>
> We do not enable CONFIG_DM_PCI_COMPAT.
That is interesting as pci_map_bar() function is declared in section:
#if !defined(CONFIG_DM_PCI) || defined(CONFIG_DM_PCI_COMPAT)
So without COMPAT macro it should not be possible to use pci_map_bar()
function at all.
> >
> > > + cmd_reg = bp->cmd_reg | PCI_COMMAND_MEMORY |
> > PCI_COMMAND_MASTER;
> > > + cmd_reg |= PCI_COMMAND_INTX_DISABLE; /* disable intr */
> > > + pci_write_word(bp->pdev, PCI_COMMAND, cmd_reg);
> > > + pci_read_word16(bp->pdev, PCI_COMMAND, _reg);
> > > + dbg_pci(bp, __func__, cmd_reg);
> > > +}
> > ...
> > > +static int bnxt_read_rom_hwaddr(struct udevice *dev)
> > > +{
> > > + struct eth_pdata *plat = dev_get_plat(dev);
> > > + struct bnxt *bp = dev_get_priv(dev);
> > > +
> > > + bnxt_bring_pci(bp);
> > > +
> > > + if (bnxt_bring_chip(bp))
> >
> > It looks suspicious if read_rom_hwaddr() function is doing
> > initialization of PCIe device. Is there any reason for it in this place?
> >
> > Opposite of bnxt_bring_pci+bnxt_bring_chip is bnxt_down_chip and it is
> > called in bnxt_eth_remove() function.
>
> The method bnxt_bring_pci() fills priv data bp and needs to be called
> before bnxt_bring_chip(). The data does not need to be cleaned in
> bnxt_eth_remove().
> We were asked by another reviewer to use bnxt_read_rom_hwaddr() to set up
> hw address (instead of doing it in probe)
Yes, that is correct way.
> but bnxt_bring_chip() has to be
> called to get the hw addr. So both methods bnxt_bring_pci and
> bnxt_bring_chip were moved there.
>
> >
> > > + printf("*** warning: bnxt_bring_chip failed! ***\n");
> >
> > It is only warning? I guess that failed initialization is fatal error
> > and should be propagated via return value... but that is not easily
> > possible if initialization is called from read_rom_hwaddr().
>
> It is only warning, since there is usually another 1G eth available,
> besides this 100G bnxt eth. Originally, we had it probed via bnxt commands
> on demand. But another reviewer asked to remove bnxt commands so we bring
> up bnxt each boot. But it is not necessarily an error causing the boot to
> fail.
Ok! So let it as is for now.
[PATCH v7 2/2] board: brcm-ns3: Load netXtreme firmware
From: Bharat Gooty
Load NetXtreme firmware in board_init when BNXT_ETH is selected.
Signed-off-by: Bharat Gooty
Signed-off-by: Roman Bacik
---
(no changes since v4)
Changes in v4:
- remove bnxt commands
- load bnxt firmware in board_init
Changes in v3:
- remove commands set/get mac/speed
- add doc/bnxt.rst
board/broadcom/bcmns3/ns3.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
index 32acf367842a..88036c16c951 100644
--- a/board/broadcom/bcmns3/ns3.c
+++ b/board/broadcom/bcmns3/ns3.c
@@ -150,7 +150,10 @@ int board_init(void)
if (bl33_info->version != BL33_INFO_VERSION)
printf("*** warning: ATF BL31 and U-Boot not in sync! ***\n");
-
+#if CONFIG_IS_ENABLED(BNXT_ETH)
+ if (chimp_fastboot_optee() != 0)
+ printf("*** warning: secure chimp fastboot failed! ***\n");
+#endif
return 0;
}
--
2.17.1
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On 11/5/21 20:17, Tom Rini wrote: On Fri, Nov 05, 2021 at 07:37:02PM +0100, Heinrich Schuchardt wrote: On 11/5/21 17:12, Simon Glass wrote: Hi, On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: Hi Andre, Added Tom to Cc. On 05.11.21 11:04, Andre Przywara wrote: On Thu, 4 Nov 2021 20:02:41 -0600 Simon Glass wrote: Hi, On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: Hi Andre, On 05.11.21 00:11, Andre Przywara wrote: On Thu, 4 Nov 2021 11:37:57 +0100 Stefan Roese wrote: Hi Stefan, On 04.11.21 04:55, Samuel Holland wrote: This series hooks up the watchdog uclass to automatically register watchdog devices for use with sysreset, doing a bit of minor cleanup along the way. The goal is for this to replace the sunxi board-level non-DM reset_cpu() function. I was surprised to find that the wdt_reboot driver requires its own undocumented device tree node, which references the watchdog device by phandle. This is problematic for us, because sunxi-u-boot.dtsi file covers 20 different SoCs with varying watchdog node phandle names. So it would have required adding a -u-boot.dtsi file for each board. Hooking things up automatically makes sense to me; this is what Linux does. However, I put the code behind a new option to avoid surprises for other platforms. Changes in v3: - Move condition to wdt-uclass.c to fix build errors. - Include watchdog name in error message. Changes in v2: - Extend the "if SYSRESET" block to the end of the file. - Also make gpio_reboot_probe function static. - Rebase on top of 492ee6b8d0e7 (now handle all watchdogs). - Added patches 5-6 as an example of how the new option will be used. Samuel Holland (6): sysreset: Add uclass Kconfig dependency to drivers sysreset: Mark driver probe functions as static sysreset: watchdog: Move watchdog reference to plat data watchdog: Automatically register device with sysreset sunxi: Avoid duplicate reset_cpu with SYSRESET enabled sunxi: Use sysreset framework for poweroff/reset arch/arm/Kconfig | 3 +++ arch/arm/mach-sunxi/board.c | 2 ++ drivers/sysreset/Kconfig | 11 ++-- drivers/sysreset/sysreset_gpio.c | 2 +- drivers/sysreset/sysreset_resetctl.c | 2 +- drivers/sysreset/sysreset_syscon.c | 2 +- drivers/sysreset/sysreset_watchdog.c | 40 ++-- drivers/watchdog/wdt-uclass.c| 8 ++ include/sysreset.h | 10 +++ 9 files changed, 67 insertions(+), 13 deletions(-) Applied to u-boot-marvell Mmmh, why u-boot-marvell, Because I'm handling watchdog related changed since a few years and we did not create a specific subsystem repo for this and I'm usually using my "marvell" one for this. And fwiw, there's a few other cases like this. If it's too confusing, maybe we should just roll out a few more repositories, I think it's easier to do that now than pre-gitlab? and why did this end up already in master? Isn't that material for the next merge window? After all this changes quite a bit, for a lot of boards, and I did not have a closer look at the sunxi parts yet. I was hesitating also a bit. But since this patchset is on the list in v1 since over 2 months now (2021-08-21) I thought it was "ready" for inclusion now. We are at -rc1 and I think we still have enough time to fix any resulting problems in this release cycle. Why do we have the merge window then? This is clearly not a regression or general fix. AFAIU, we are a bit less strict here in U-Boot. Patches that were posted before the merge-window and skipped the review process (most likely because of lack of time) are often still integrated in the early rcX cycles. At least this is how I handle it usually. Tom, is my understanding here correct? Yes. We are not as strict as the kernel is about what can come in between rc1 and rc2 (and to a certain degree, post rc2). I leave things up to the discretion of the custodians. People tend of have less time to handle U-Boot changes than other stuff, so I try and be flexible in picking things up. Yes I agree, that should be plenty of time for people to review it. Well, if there would be people to review the sunxi parts :-( I am totally fine with the generic patches (as they have been reviewed), but the sunxi integration is somewhat risky. I was explicitly deprioritising that in my queue, as it really doesn't change, add or fix anything, it's mere refactoring, from the user's point of view. Do you see any specific issues? Patch 6/6 changes the config for all 157 Allwinner boards, so I think that deserves at least some testing, *before* merging it. I expect that Samuel did some testing. But still, I agree that it would be much better, if these patches - especially the Allwinner parts got more extensive testing. I will
[PATCH v1 2/2] image: Explicitly declare do_bdinfo()
Compiler is not happy: common/image-board.c: In function ‘boot_get_kbd’: common/image-board.c:902:17: warning: implicit declaration of function ‘do_bdinfo’ [-Wimplicit-function-declaration] 902 | do_bdinfo(NULL, 0, 0, NULL); | ^ Move the forward declaration to a header. Signed-off-by: Andy Shevchenko --- common/image.c | 5 - include/init.h | 5 + 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/common/image.c b/common/image.c index 3fa60b582796..57bf86278149 100644 --- a/common/image.c +++ b/common/image.c @@ -29,11 +29,6 @@ #include #include -#ifdef CONFIG_CMD_BDI -extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, -char *const argv[]); -#endif - DECLARE_GLOBAL_DATA_PTR; /* Set this if we have less than 4 MB of malloc() space */ diff --git a/include/init.h b/include/init.h index c781789e367e..37ca9905414f 100644 --- a/include/init.h +++ b/include/init.h @@ -332,6 +332,11 @@ void bdinfo_print_mhz(const char *name, unsigned long hz); /* Show arch-specific information for the 'bd' command */ void arch_print_bdinfo(void); +#if defined(CONFIG_CMD_BDI) +extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, +char *const argv[]); +#endif + #endif /* __ASSEMBLY__ */ /* Put only stuff here that the assembler can digest */ -- 2.33.0
[PATCH v1 1/2] image: Fix typo in boot_get_kbd()
After the commit 4ed37abc49c2 ("image: Remove ifdefs around
image_setup_linux() el at"):
common/image-board.c: In function ‘boot_get_kbd’:
common/image-board.c:902:17: error: expected ‘)’ before ‘do_bdinfo’
902 | do_bdinfo(NULL, 0, 0, NULL);
| ^
common/image-board.c:901:12: note: to match this ‘(’
901 | if (IS_ENABLED(CONFIG_CMD_BDI)
|^
common/image-board.c:906:1: error: expected expression before ‘}’ token
906 | }
| ^
common/image-board.c:906:1: warning: control reaches end of non-void function
[-Wreturn-type]
906 | }
| ^
Fix obvious typo.
Fixes: 4ed37abc49c2 ("image: Remove ifdefs around image_setup_linux() el at")
Signed-off-by: Andy Shevchenko
Revert "image: Partially revert too aggressive ifdeferry removal"
This reverts commit 84631af9d0454ff8252c1aebb1e9c232b8077692.
Signed-off-by: Andy Shevchenko
---
common/image-board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/image-board.c b/common/image-board.c
index e7660352e96a..ddf30c67302e 100644
--- a/common/image-board.c
+++ b/common/image-board.c
@@ -898,7 +898,7 @@ int boot_get_kbd(struct lmb *lmb, struct bd_info **kbd)
debug("## kernel board info at 0x%08lx\n", (ulong)*kbd);
#if defined(DEBUG)
- if (IS_ENABLED(CONFIG_CMD_BDI)
+ if (IS_ENABLED(CONFIG_CMD_BDI))
do_bdinfo(NULL, 0, 0, NULL);
#endif
--
2.33.0
Re: Booting zImage with appended DTB without ATAGs support
On Fri, Nov 05, 2021 at 04:47:31PM +0100, Pali Rohár wrote: > On Friday 05 November 2021 11:20:01 Tom Rini wrote: > > On Fri, Nov 05, 2021 at 04:16:46PM +0100, Pali Rohár wrote: > > > So now I have a question: Do we want to support booting zImage with > > > appended DTB in U-Boot when ATAGs support is now disabled by default? > > > > Based on your experience, yes, there are use cases for appended dtb > > booting still. So it should be at least documented what you need to do > > where in order for that to work, and perhaps some platforms will want to > > enable it by default. > > What could be implemented in U-Boot is extracting DTB from zImage+DTB > binary and boot it like if user supply separate zImage and separate DTB > files. With this approach there is no need to have ATAGs support > enabled. It would mean that kernel's code for using attached DTB would > not be used anymore as DTB would be passed to kernel separately, like > any modern boot setup. > > Main issue with this approach is that if you load zImage+DTB binary from > disk or UART into memory then you loose information about total binary > size. And if you examine memory after the zImage, you cannot be sure if > data were loaded by previous command (disk read, UART transfer) or if is > just some garbage in RAM. So you can have false-positive detection that > DTB was appended. > > This issue does not happen in case of booting zImage+DTB encapsulated in > uImage format, as in uImage is stored total size of that concatenated > binary. So booting via bootm should be fine. IIRC zImage+DTB-in-uImage > via bootm is used for booting new kernels on Nokia N900. > > Currently affected by this issue is bootz command, which takes only > start address of the zImage binary and total size is not specified. > Command bootz takes third argument which specifies location of DTB in > memory and understand special value "-" which says to atags booting. > I'm thinking here... what about adding a new special value e.g. "+" > which would mean that DTB is attached to zImage? This could issue that > automatic detection of attached DTB into zImage is not reliable. > > Any opinion? > > Another approach instead of extracting DTB from zImage+DTB binary could > be to teach U-Boot to provide some simple minimalistic ATAGs and then > boot those zImage+DTB binaries like before with minimalistic ATAGs... So, there's certainly still valid reasons and times to boot an appended DTB. It's just not a generally common case I think. But it does show that ATAGs were getting a bit more use still than I had expected. I think we should update the help / prompt on SUPPORT_PASSING_ATAGS to make it clear this is needed for appended dtb booting and if I followed you right, CMDLINE should at least also be enabled for that case, and maybe also update something under doc/. I don't think we should put too much effort in to making us find and pass the appended dtb for what is an otherwise niche case. -- Tom signature.asc Description: PGP signature
RE: [PATCH v6 1/2] net: brcm: netXtreme driver
Hi Pali, > -Original Message- > From: Pali Rohár > Sent: Wednesday, November 3, 2021 4:14 PM > To: Roman Bacik > Cc: U-Boot Mailing List ; Bharat Gooty > ; Joe Hershberger > ; Ramon Fried > Subject: Re: [PATCH v6 1/2] net: brcm: netXtreme driver > > Hello! See inline comments below. > > On Tuesday 02 November 2021 11:18:10 Roman Bacik wrote: > > From: Bharat Gooty > > > > Broadcom bnxt L2 driver support. Used by the Broadcom > > iproc platforms. > > > > Signed-off-by: Bharat Gooty > > Reviewed-by: Ramon Fried > > > > Signed-off-by: Roman Bacik > > --- > > > > Changes in v6: > > - remove bnxt_eth_* env variables > > - clean up include headers > > > > Changes in v5: > > - remove bnxt_env_set_ethaddr/bnxt_env_del_ethaddr methods > > - add .read_rom_hwaddr = bnxt_read_rom_hwaddr > > - move bnxt_bring_pci/bnxt_bring_chip to bnxt_read_rom_hwddr > > - move mac copy from priv to plat to bnxt_read_rom_hwaddr > > > > Changes in v4: > > - remove static num_cards and use dev_seq(dev) instead > > - add .probe > > - merged probe/remove methods > > - select PCI_INIT_R when BNXT_ETH is selected > > > > Changes in v3: > > - change printf to debug in display_banner > > - remove get/set/print mac/speed > > - remove bnxt_hwrm_set_nvmem > > > > Changes in v2: > > - rebase and remove DM_PCI dependency from BNXT_ETH > > - remove tautology assignment from debug_resp() > > > > drivers/net/Kconfig |1 + > > drivers/net/Makefile|1 + > > drivers/net/bnxt/Kconfig|7 + > > drivers/net/bnxt/Makefile |5 + > > drivers/net/bnxt/bnxt.c | 1727 > +++ > > drivers/net/bnxt/bnxt_dbg.h | 537 +++ > > drivers/net/bnxt/pci_ids.h | 17 + > > include/broadcom/bnxt.h | 395 > > include/broadcom/bnxt_hsi.h | 889 ++ > > include/broadcom/bnxt_ver.h | 22 + > > These 3 include files looks like that contain only private definitions > for bnxt driver. So should not they be in the drivers/net/bnxt directory? We will move these files to drivers/net/bnxt/. > > > 10 files changed, 3601 insertions(+) > > create mode 100644 drivers/net/bnxt/Kconfig > > create mode 100644 drivers/net/bnxt/Makefile > > create mode 100644 drivers/net/bnxt/bnxt.c > > create mode 100644 drivers/net/bnxt/bnxt_dbg.h > > create mode 100644 drivers/net/bnxt/pci_ids.h > > create mode 100644 include/broadcom/bnxt.h > > create mode 100644 include/broadcom/bnxt_hsi.h > > create mode 100644 include/broadcom/bnxt_ver.h > > > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > > index 6c12959f3794..8dc81a3d6cf9 100644 > > --- a/drivers/net/Kconfig > > +++ b/drivers/net/Kconfig > > @@ -1,6 +1,7 @@ > > source "drivers/net/phy/Kconfig" > > source "drivers/net/pfe_eth/Kconfig" > > source "drivers/net/fsl-mc/Kconfig" > > +source "drivers/net/bnxt/Kconfig" > > > > config ETH > > def_bool y > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > > index e4078d15a99f..1d9fbd6693cc 100644 > > --- a/drivers/net/Makefile > > +++ b/drivers/net/Makefile > > @@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o > > obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o > > obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o > > obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o > > +obj-$(CONFIG_BNXT_ETH) += bnxt/ > > diff --git a/drivers/net/bnxt/Kconfig b/drivers/net/bnxt/Kconfig > > new file mode 100644 > > index ..412ecd430335 > > --- /dev/null > > +++ b/drivers/net/bnxt/Kconfig > > @@ -0,0 +1,7 @@ > > +config BNXT_ETH > > + bool "BNXT PCI support" > > + depends on DM_ETH > > + select PCI_INIT_R > > + help > > + This driver implements support for bnxt pci controller > > + driver of ethernet class. > > diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile > > new file mode 100644 > > index ..a9d6ce00d5e0 > > --- /dev/null > > +++ b/drivers/net/bnxt/Makefile > > @@ -0,0 +1,5 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# Copyright 2019-2021 Broadcom. > > + > > +# Broadcom nxe Ethernet driver > > +obj-y += bnxt.o > > diff --git a/drivers/net/bnxt/bnxt.c b/drivers/net/bnxt/bnxt.c > > new file mode 100644 > > index ..60a65b20a8f1 > > --- /dev/null > > +++ b/drivers/net/bnxt/bnxt.c > > @@ -0,0 +1,1727 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Copyright 2019-2021 Broadcom. > > + */ > > + > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "bnxt_dbg.h" > > +#include "pci_ids.h" > > + > > +#define bnxt_down_chip(bp) bnxt_hwrm_run(down_chip, bp, 0) > > +#define bnxt_bring_chip(bp)bnxt_hwrm_run(bring_chip, bp, 1) > > + > > +static const char banner[] = DRV_MODULE_DESC " v" > UBOOT_MODULE_VER ","; > > You do not need banner with custom version number. U-Boot version is > printed automatically and specify also which version of driver includes. We will remove
Re: [PATCH 10/10] Convert CONFIG_BOARD_EARLY_INIT_F et al to Kconfig
On Sat, Oct 30, 2021 at 11:03:57PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_BOARD_EARLY_INIT_F >CONFIG_BOARD_LATE_INIT >CONFIG_DISPLAY_BOARDINFO >CONFIG_DISPLAY_BOARDINFO_LATE > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/10] Convert CONFIG_SPL_DRIVERS_MISC et al to Kconfig
On Sat, Oct 30, 2021 at 11:03:56PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SPL_DRIVERS_MISC >CONFIG_SPL_ENV_SUPPORT >CONFIG_SPL_GPIO >CONFIG_SPL_I2C >CONFIG_SPL_LDSCRIPT >CONFIG_SPL_LIBCOMMON_SUPPORT >CONFIG_SPL_LIBGENERIC_SUPPORT >CONFIG_SPL_LOAD_FIT_ADDRESS >CONFIG_SPL_MMC >CONFIG_SPL_NAND_SUPPORT >CONFIG_SPL_NO_CPU_SUPPORT >CONFIG_SPL_OS_BOOT >CONFIG_SPL_POWER >CONFIG_SPL_STACK_R >CONFIG_SPL_STACK_R_ADDR >CONFIG_SPL_WATCHDOG >CONFIG_SPL_TEXT_BASE > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 08/10] Convert CONFIG_BMP_16BPP to Kconfig
On Sat, Oct 30, 2021 at 11:03:55PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_BMP_16BPP > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/10] Convert CONFIG_OF_EMBED to Kconfig
On Sat, Oct 30, 2021 at 11:03:54PM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_OF_EMBED > > Signed-off-by: Tom Rini > Reviewed-by: Rick Chen Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 06/10] Convert CONFIG_MCFUART to Kconfig
On Sat, Oct 30, 2021 at 11:03:53PM -0400, Tom Rini wrote: > This converts the following to Kconfig: > CONFIG_MCFUART > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/10] Convert CONFIG_FEC_MXC to Kconfig
On Sat, Oct 30, 2021 at 11:03:52PM -0400, Tom Rini wrote: > This converts the following to Kconfig: > CONFIG_FEC_MXC > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/10] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
On Sat, Oct 30, 2021 at 11:03:51PM -0400, Tom Rini wrote: > This converts the following to Kconfig: > CONFIG_SUPPORT_EMMC_BOOT > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/10] Convert CONFIG_SYS_TEXT_BASE to Kconfig
On Sat, Oct 30, 2021 at 11:03:50PM -0400, Tom Rini wrote: > This converts the following to Kconfig: > CONFIG_SYS_TEXT_BASE > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/10] Convert CONFIG_SYS_HZ to Kconfig
On Sat, Oct 30, 2021 at 11:03:49PM -0400, Tom Rini wrote: > This converts the following to Kconfig: > CONFIG_SYS_HZ > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/10] spl: Make use of CONFIG_IS_ENABLED(OS_BOOT) in SPL/TPL common code paths
On Sat, Oct 30, 2021 at 11:03:48PM -0400, Tom Rini wrote: > When building a system that has both TPL and SPL_OS_BOOT, code which > tests for CONFIG_SPL_OS_BOOT will be built and enabled in TPL, which is > not correct. While there is no CONFIG_TPL_OS_BOOT symbol at this time > (and likely will not ever be) we can use CONFIG_IS_ENABLED(OS_BOOT) in > these common paths to ensure we only compile these parts in the SPL > case. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: yaffs2: Finish Kconfig migration
On Tue, Oct 19, 2021 at 09:10:14PM -0400, Tom Rini wrote: > For the symbols which are both hard-coded as enabled and used, move to > Kconfig. The rest of the CONFIG_YAFFS namespace is unselected anywhere, > so we leave it as is. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
Hi Andre, On Fri, 5 Nov 2021 at 11:07, Andre Przywara wrote: > > On Fri, 5 Nov 2021 10:12:11 -0600 > Simon Glass wrote: > > Hi, > > > On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: > > > > > > On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: > > > > Hi Andre, > > > > > > > > Added Tom to Cc. > > > > > > > > On 05.11.21 11:04, Andre Przywara wrote: > > > > > On Thu, 4 Nov 2021 20:02:41 -0600 > > > > > Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > > On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: > > > > > > > > > > > > > > Hi Andre, > > > > > > > > > > > > > > On 05.11.21 00:11, Andre Przywara wrote: > > > > > > > > On Thu, 4 Nov 2021 11:37:57 +0100 > > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > > > Hi Stefan, > > > > > > > > > On 04.11.21 04:55, Samuel Holland wrote: > > > > > > > > > > This series hooks up the watchdog uclass to automatically > > > > > > > > > > register > > > > > > > > > > watchdog devices for use with sysreset, doing a bit of > > > > > > > > > > minor cleanup > > > > > > > > > > along the way. > > > > > > > > > > > > > > > > > > > > The goal is for this to replace the sunxi board-level > > > > > > > > > > non-DM reset_cpu() > > > > > > > > > > function. I was surprised to find that the wdt_reboot > > > > > > > > > > driver requires > > > > > > > > > > its own undocumented device tree node, which references the > > > > > > > > > > watchdog > > > > > > > > > > device by phandle. This is problematic for us, because > > > > > > > > > > sunxi-u-boot.dtsi > > > > > > > > > > file covers 20 different SoCs with varying watchdog node > > > > > > > > > > phandle names. > > > > > > > > > > So it would have required adding a -u-boot.dtsi file for > > > > > > > > > > each board. > > > > > > > > > > > > > > > > > > > > Hooking things up automatically makes sense to me; this is > > > > > > > > > > what Linux > > > > > > > > > > does. However, I put the code behind a new option to avoid > > > > > > > > > > surprises for > > > > > > > > > > other platforms. > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > - Move condition to wdt-uclass.c to fix build errors. > > > > > > > > > > - Include watchdog name in error message. > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > - Extend the "if SYSRESET" block to the end of the file. > > > > > > > > > > - Also make gpio_reboot_probe function static. > > > > > > > > > > - Rebase on top of 492ee6b8d0e7 (now handle all > > > > > > > > > > watchdogs). > > > > > > > > > > - Added patches 5-6 as an example of how the new option > > > > > > > > > > will be used. > > > > > > > > > > > > > > > > > > > > Samuel Holland (6): > > > > > > > > > > sysreset: Add uclass Kconfig dependency to drivers > > > > > > > > > > sysreset: Mark driver probe functions as static > > > > > > > > > > sysreset: watchdog: Move watchdog reference to plat > > > > > > > > > > data > > > > > > > > > > watchdog: Automatically register device with sysreset > > > > > > > > > > sunxi: Avoid duplicate reset_cpu with SYSRESET enabled > > > > > > > > > > sunxi: Use sysreset framework for poweroff/reset > > > > > > > > > > > > > > > > > > > > arch/arm/Kconfig | 3 +++ > > > > > > > > > > arch/arm/mach-sunxi/board.c | 2 ++ > > > > > > > > > > drivers/sysreset/Kconfig | 11 ++-- > > > > > > > > > > drivers/sysreset/sysreset_gpio.c | 2 +- > > > > > > > > > > drivers/sysreset/sysreset_resetctl.c | 2 +- > > > > > > > > > > drivers/sysreset/sysreset_syscon.c | 2 +- > > > > > > > > > > drivers/sysreset/sysreset_watchdog.c | 40 > > > > > > > > > > ++-- > > > > > > > > > > drivers/watchdog/wdt-uclass.c| 8 ++ > > > > > > > > > > include/sysreset.h | 10 +++ > > > > > > > > > > 9 files changed, 67 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > > > > > Applied to u-boot-marvell > > > > > > > > > > > > > > > > Mmmh, why u-boot-marvell, > > > > > > > > > > > > > > Because I'm handling watchdog related changed since a few years > > > > > > > and we > > > > > > > did not create a specific subsystem repo for this and I'm usually > > > > > > > using my "marvell" one for this. > > > > > > And fwiw, there's a few other cases like this. If it's too confusing, > > > maybe we should just roll out a few more repositories, I think it's > > > easier to do that now than pre-gitlab? > > No, that's fine, I was just briefly confused about the Marvell part. > > > > > > > > > and why did this end up already in master? > > > > > > > > Isn't that material for the next merge window? After all this > > > > > > > > changes > > > > > > > > quite a bit, for a lot of boards, and I did not have a closer > > > > > > > > look at > > > > > > > > the sunxi parts yet. > > > > > > > > > > > > > > I was hesitating also
Re: "mmc: rockchip_sdhci: add phy and clock config for rk3399" broke spl emmc boot
On 05/11/2021 19:03, Alistair Delva wrote: > Hi Yifeng, > > Since "mmc: rockchip_sdhci: add phy and clock config for rk3399", my > RockPi 4b device can't boot off of eMMC. It will start tpl/spl and > then fail: > > U-Boot TPL 2021.10-rc1-gac804143cf-dirty (Aug 11 2021 - 10:02:07) > Channel 0: LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > Channel 1: LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > 256B stride > lpddr4_set_rate: change freq to 4 mhz 0, 1 > lpddr4_set_rate: change freq to 8 mhz 1, 0 > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2021.10-rc1-gac804143cf-dirty (Aug 11 2021 - 10:02:07 +) > Trying to boot from MMC1 > Card did not respond to voltage select! : -110 > spl: mmc init failed with error: -95 > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > If I revert these changes, all is well: > > commit a63a57e59d864a1ca2b0acb5fadc5c3579c3e79c > Author: Yifeng Zhao > Date: Tue Jun 29 16:24:42 2021 +0800 > >mmc: rockchip_sdhci: Add support for RK3568 > > commit ac804143cfd128d144403ef2434344988c3fde9f (refs/bisect/bad) > Author: Yifeng Zhao > Date: Tue Jun 29 16:24:41 2021 +0800 > >mmc: rockchip_sdhci: add phy and clock config for rk3399 > > Please let me know if you need help to test this. > > Thanks, > Alistair. > Hi Alistair, You need the following patch: https://patchwork.ozlabs.org/project/uboot/patch/20211101044347.17822-1-yifeng.z...@rock-chips.com/ Please let me know if this fixes the issue for you as some people still have outstanding issues with this set of patches when the emmc is run the HS200/400 modes. Regards, Jack. -- Jack Mitchell, Consultant https://www.tuxable.co.uk
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On Fri, Nov 05, 2021 at 07:37:02PM +0100, Heinrich Schuchardt wrote: > On 11/5/21 17:12, Simon Glass wrote: > > Hi, > > > > On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: > > > > > > On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: > > > > Hi Andre, > > > > > > > > Added Tom to Cc. > > > > > > > > On 05.11.21 11:04, Andre Przywara wrote: > > > > > On Thu, 4 Nov 2021 20:02:41 -0600 > > > > > Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > > On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: > > > > > > > > > > > > > > Hi Andre, > > > > > > > > > > > > > > On 05.11.21 00:11, Andre Przywara wrote: > > > > > > > > On Thu, 4 Nov 2021 11:37:57 +0100 > > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > > > Hi Stefan, > > > > > > > > > On 04.11.21 04:55, Samuel Holland wrote: > > > > > > > > > > This series hooks up the watchdog uclass to automatically > > > > > > > > > > register > > > > > > > > > > watchdog devices for use with sysreset, doing a bit of > > > > > > > > > > minor cleanup > > > > > > > > > > along the way. > > > > > > > > > > > > > > > > > > > > The goal is for this to replace the sunxi board-level > > > > > > > > > > non-DM reset_cpu() > > > > > > > > > > function. I was surprised to find that the wdt_reboot > > > > > > > > > > driver requires > > > > > > > > > > its own undocumented device tree node, which references the > > > > > > > > > > watchdog > > > > > > > > > > device by phandle. This is problematic for us, because > > > > > > > > > > sunxi-u-boot.dtsi > > > > > > > > > > file covers 20 different SoCs with varying watchdog node > > > > > > > > > > phandle names. > > > > > > > > > > So it would have required adding a -u-boot.dtsi file for > > > > > > > > > > each board. > > > > > > > > > > > > > > > > > > > > Hooking things up automatically makes sense to me; this is > > > > > > > > > > what Linux > > > > > > > > > > does. However, I put the code behind a new option to avoid > > > > > > > > > > surprises for > > > > > > > > > > other platforms. > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > - Move condition to wdt-uclass.c to fix build errors. > > > > > > > > > > - Include watchdog name in error message. > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > - Extend the "if SYSRESET" block to the end of the > > > > > > > > > > file. > > > > > > > > > > - Also make gpio_reboot_probe function static. > > > > > > > > > > - Rebase on top of 492ee6b8d0e7 (now handle all > > > > > > > > > > watchdogs). > > > > > > > > > > - Added patches 5-6 as an example of how the new > > > > > > > > > > option will be used. > > > > > > > > > > > > > > > > > > > > Samuel Holland (6): > > > > > > > > > > sysreset: Add uclass Kconfig dependency to drivers > > > > > > > > > > sysreset: Mark driver probe functions as static > > > > > > > > > > sysreset: watchdog: Move watchdog reference to plat > > > > > > > > > > data > > > > > > > > > > watchdog: Automatically register device with sysreset > > > > > > > > > > sunxi: Avoid duplicate reset_cpu with SYSRESET enabled > > > > > > > > > > sunxi: Use sysreset framework for poweroff/reset > > > > > > > > > > > > > > > > > > > > arch/arm/Kconfig | 3 +++ > > > > > > > > > > arch/arm/mach-sunxi/board.c | 2 ++ > > > > > > > > > > drivers/sysreset/Kconfig | 11 ++-- > > > > > > > > > > drivers/sysreset/sysreset_gpio.c | 2 +- > > > > > > > > > > drivers/sysreset/sysreset_resetctl.c | 2 +- > > > > > > > > > > drivers/sysreset/sysreset_syscon.c | 2 +- > > > > > > > > > > drivers/sysreset/sysreset_watchdog.c | 40 > > > > > > > > > > ++-- > > > > > > > > > > drivers/watchdog/wdt-uclass.c| 8 ++ > > > > > > > > > > include/sysreset.h | 10 +++ > > > > > > > > > > 9 files changed, 67 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > > > > > Applied to u-boot-marvell > > > > > > > > > > > > > > > > Mmmh, why u-boot-marvell, > > > > > > > > > > > > > > Because I'm handling watchdog related changed since a few years > > > > > > > and we > > > > > > > did not create a specific subsystem repo for this and I'm usually > > > > > > > using my "marvell" one for this. > > > > > > And fwiw, there's a few other cases like this. If it's too confusing, > > > maybe we should just roll out a few more repositories, I think it's > > > easier to do that now than pre-gitlab? > > > > > > > > > > > and why did this end up already in master? > > > > > > > > Isn't that material for the next merge window? After all this > > > > > > > > changes > > > > > > > > quite a bit, for a lot of boards, and I did not have a closer > > > > > > > > look at > > > > > > > > the sunxi parts yet. > > > > > > > > > > > > > > I was hesitating also a bit. But since
[PATCH 6/6 v5] MAINTAINERS: Add entry for TPM drivers
TPM drivers have currently no maintainers. Add myself since I contributed the TIS implementation. Reviewed-by: Heinrich Schuchardt Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d8cba902800..f02901c55de5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1183,6 +1183,11 @@ F: configs/am65x_hs_evm_a53_defconfig F: configs/j721e_hs_evm_r5_defconfig F: configs/j721e_hs_evm_a72_defconfig +TPM DRIVERS +M: Ilias Apalodimas +S: Maintained +F: drivers/tpm/ + TQ GROUP #M:Martin Krause S: Orphaned (Since 2016-02) -- 2.33.1
[PATCH 3/6 v5] tpm: Use the new API on tpm2 spi driver
Convert our SPI TPM driver and use the newly added API
Reviewed-by: Simon Glass
Signed-off-by: Ilias Apalodimas
---
drivers/tpm/Makefile | 2 +-
drivers/tpm/tpm2_tis_spi.c | 447 +++--
2 files changed, 32 insertions(+), 417 deletions(-)
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index 494aa5a46d30..51725230c780 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -12,6 +12,6 @@ obj-$(CONFIG_TPM_ST33ZP24_SPI) += tpm_tis_st33zp24_spi.o
obj-$(CONFIG_$(SPL_TPL_)TPM2_CR50_I2C) += cr50_i2c.o
obj-$(CONFIG_TPM2_TIS_SANDBOX) += tpm2_tis_sandbox.o sandbox_common.o
-obj-$(CONFIG_TPM2_TIS_SPI) += tpm2_tis_spi.o
+obj-$(CONFIG_TPM2_TIS_SPI) += tpm2_tis_core.o tpm2_tis_spi.o
obj-$(CONFIG_TPM2_FTPM_TEE) += tpm2_ftpm_tee.o
obj-$(CONFIG_TPM2_MMIO) += tpm2_tis_core.o tpm2_tis_mmio.o
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 1d24d32d867e..58b6f3351057 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -30,13 +30,6 @@
#include "tpm_tis.h"
#include "tpm_internal.h"
-#define TPM_ACCESS(l) (0x | ((l) << 12))
-#define TPM_INT_ENABLE(l) (0x0008 | ((l) << 12))
-#define TPM_STS(l) (0x0018 | ((l) << 12))
-#define TPM_DATA_FIFO(l) (0x0024 | ((l) << 12))
-#define TPM_DID_VID(l) (0x0F00 | ((l) << 12))
-#define TPM_RID(l) (0x0F04 | ((l) << 12))
-
#define MAX_SPI_FRAMESIZE 64
/* Number of wait states to wait for */
@@ -165,7 +158,7 @@ release_bus:
return ret;
}
-static int tpm_tis_spi_read(struct udevice *dev, u16 addr, u8 *in, u16 len)
+static int tpm_tis_spi_read(struct udevice *dev, u32 addr, u16 len, u8 *in)
{
return tpm_tis_spi_xfer(dev, addr, NULL, in, len);
}
@@ -175,382 +168,24 @@ static int tpm_tis_spi_read32(struct udevice *dev, u32
addr, u32 *result)
__le32 result_le;
int ret;
- ret = tpm_tis_spi_read(dev, addr, (u8 *)_le, sizeof(u32));
+ ret = tpm_tis_spi_read(dev, addr, sizeof(u32), (u8 *)_le);
if (!ret)
*result = le32_to_cpu(result_le);
return ret;
}
-static int tpm_tis_spi_write(struct udevice *dev, u16 addr, const u8 *out,
-u16 len)
-{
- return tpm_tis_spi_xfer(dev, addr, out, NULL, len);
-}
-
-static int tpm_tis_spi_check_locality(struct udevice *dev, int loc)
-{
- const u8 mask = TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID;
- struct tpm_chip *chip = dev_get_priv(dev);
- u8 buf;
- int ret;
-
- ret = tpm_tis_spi_read(dev, TPM_ACCESS(loc), , 1);
- if (ret)
- return ret;
-
- if ((buf & mask) == mask) {
- chip->locality = loc;
- return 0;
- }
-
- return -ENOENT;
-}
-
-static void tpm_tis_spi_release_locality(struct udevice *dev, int loc,
-bool force)
-{
- const u8 mask = TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID;
- u8 buf;
- if (tpm_tis_spi_read(dev, TPM_ACCESS(loc), , 1) < 0)
- return;
-
- if (force || (buf & mask) == mask) {
- buf = TPM_ACCESS_ACTIVE_LOCALITY;
- tpm_tis_spi_write(dev, TPM_ACCESS(loc), , 1);
- }
-}
-
-static int tpm_tis_spi_request_locality(struct udevice *dev, int loc)
+static int tpm_tis_spi_write(struct udevice *dev, u32 addr, u16 len, const u8
*out)
{
- struct tpm_chip *chip = dev_get_priv(dev);
- unsigned long start, stop;
- u8 buf = TPM_ACCESS_REQUEST_USE;
- int ret;
-
- ret = tpm_tis_spi_check_locality(dev, loc);
- if (!ret)
- return 0;
-
- if (ret != -ENOENT) {
- log(LOGC_NONE, LOGL_ERR, "%s: Failed to get locality: %d\n",
- __func__, ret);
- return ret;
- }
-
- ret = tpm_tis_spi_write(dev, TPM_ACCESS(loc), , 1);
- if (ret) {
- log(LOGC_NONE, LOGL_ERR, "%s: Failed to write to TPM: %d\n",
- __func__, ret);
- return ret;
- }
-
- start = get_timer(0);
- stop = chip->timeout_a;
- do {
- ret = tpm_tis_spi_check_locality(dev, loc);
- if (!ret)
- return 0;
-
- if (ret != -ENOENT) {
- log(LOGC_NONE, LOGL_ERR,
- "%s: Failed to get locality: %d\n", __func__, ret);
- return ret;
- }
-
- mdelay(TPM_TIMEOUT_MS);
- } while (get_timer(start) < stop);
-
- log(LOGC_NONE, LOGL_ERR, "%s: Timeout getting locality: %d\n", __func__,
- ret);
-
- return ret;
-}
-
-static u8 tpm_tis_spi_status(struct udevice *dev, u8 *status)
-{
- struct tpm_chip *chip = dev_get_priv(dev);
-
- return tpm_tis_spi_read(dev, TPM_STS(chip->locality), status, 1);
-}
-
-static int
[PATCH 5/6 v5] doc: qemu: Add instructions for swtpm usage
A previous patch added support for an mmio based TPM. Add an example in QEMU on it's usage Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas --- doc/board/emulation/qemu-arm.rst | 25 + 1 file changed, 25 insertions(+) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 8d7fda10f15e..584ef0a7e150 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -81,6 +81,31 @@ can be enabled with the following command line parameters: These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well. +Enabling TPMv2 support +-- + +To emulate a TPM the swtpm package may be used. It can be built from the +following repositories: + + https://github.com/stefanberger/swtpm.git + +Swtpm provides a socket for the TPM emulation which can be consumed by QEMU. + +In a first console invoke swtpm with:: + + swtpm socket --tpmstate dir=/tmp/mytpm1 \ + --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock --log level=20 + +In a second console invoke qemu-system-aarch64 with:: + + -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ + -tpmdev emulator,id=tpm0,chardev=chrtpm \ + -device tpm-tis-device,tpmdev=tpm0 + +Enable the TPM on U-Boot's command line with:: + +tpm2 startup TPM2_SU_CLEAR + Debug UART -- -- 2.33.1
[PATCH 4/6 v5] configs: Enable tpmv2 mmio on qemu for arm/arm64
A previous commit is adding an MMIO TPMv2 driver. Include in the default qemu arm configs, since we plan on using them on EFI testing Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas --- configs/qemu_arm64_defconfig | 2 ++ configs/qemu_arm_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig index 003717efde28..83d7ae54de4d 100644 --- a/configs/qemu_arm64_defconfig +++ b/configs/qemu_arm64_defconfig @@ -49,6 +49,8 @@ CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_SYSRESET=y CONFIG_SYSRESET_PSCI=y +CONFIG_TPM2_MMIO=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y +CONFIG_TPM=y diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index 27b0e49f6f89..ab5574847e89 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -51,6 +51,8 @@ CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_SYSRESET=y CONFIG_SYSRESET_PSCI=y +CONFIG_TPM2_MMIO=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y +CONFIG_TPM=y -- 2.33.1
[PATCH 2/6 v5] tpm2: Add a TPMv2 MMIO TIS driver
Add support for devices that expose a TPMv2 though MMIO.
Apart from those devices, we can use the driver in our QEMU setups and
test TPM related code which is difficult to achieve using the sandbox
driver (e.g test the EFI TCG2 protocol).
It's worth noting that a previous patch added TPMv2 TIS core functions,
which the current driver is consuming.
Signed-off-by: Ilias Apalodimas
---
drivers/tpm/Kconfig | 9 +++
drivers/tpm/Makefile| 1 +
drivers/tpm/tpm2_tis_mmio.c | 152
3 files changed, 162 insertions(+)
create mode 100644 drivers/tpm/tpm2_tis_mmio.c
diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig
index 9eebab5cfd90..406ee8716e1e 100644
--- a/drivers/tpm/Kconfig
+++ b/drivers/tpm/Kconfig
@@ -161,6 +161,15 @@ config TPM2_FTPM_TEE
help
This driver supports firmware TPM running in TEE.
+config TPM2_MMIO
+ bool "MMIO based TPM2 Interface"
+ depends on TPM_V2
+ help
+ This driver supports firmware TPM2.0 MMIO interface.
+ The usual TPM operations and the 'tpm' command can be used to talk
+ to the device using the standard TPM Interface Specification (TIS)
+ protocol.
+
endif # TPM_V2
endmenu
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index c65be5267002..494aa5a46d30 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_$(SPL_TPL_)TPM2_CR50_I2C) += cr50_i2c.o
obj-$(CONFIG_TPM2_TIS_SANDBOX) += tpm2_tis_sandbox.o sandbox_common.o
obj-$(CONFIG_TPM2_TIS_SPI) += tpm2_tis_spi.o
obj-$(CONFIG_TPM2_FTPM_TEE) += tpm2_ftpm_tee.o
+obj-$(CONFIG_TPM2_MMIO) += tpm2_tis_core.o tpm2_tis_mmio.o
diff --git a/drivers/tpm/tpm2_tis_mmio.c b/drivers/tpm/tpm2_tis_mmio.c
new file mode 100644
index ..223000c5cd8d
--- /dev/null
+++ b/drivers/tpm/tpm2_tis_mmio.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * driver for mmio TCG/TIS TPM (trusted platform module).
+ *
+ * Specifications at www.trustedcomputinggroup.org
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tpm_tis.h"
+#include "tpm_internal.h"
+
+/**
+ * struct tpm_tis_chip_data - Information about an MMIO TPM
+ * @pcr_count: Number of PCR per bank
+ * @pcr_select_min:Minimum size in bytes of the pcrSelect array
+ * @iobase:Base address
+ */
+struct tpm_tis_chip_data {
+ unsigned int pcr_count;
+ unsigned int pcr_select_min;
+ void __iomem *iobase;
+};
+
+static int mmio_read_bytes(struct udevice *dev, u32 addr, u16 len,
+ u8 *result)
+{
+ struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(dev);
+
+ while (len--)
+ *result++ = ioread8(drv_data->iobase + addr);
+ return 0;
+}
+
+static int mmio_write_bytes(struct udevice *dev, u32 addr, u16 len,
+ const u8 *value)
+{
+ struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(dev);
+
+ while (len--)
+ iowrite8(*value++, drv_data->iobase + addr);
+ return 0;
+}
+
+static int mmio_read32(struct udevice *dev, u32 addr, u32 *result)
+{
+ struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(dev);
+
+ *result = ioread32(drv_data->iobase + addr);
+ return 0;
+}
+
+static int mmio_write32(struct udevice *dev, u32 addr, u32 value)
+{
+ struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(dev);
+
+ iowrite32(value, drv_data->iobase + addr);
+ return 0;
+}
+
+static struct tpm_tis_phy_ops phy_ops = {
+ .read_bytes = mmio_read_bytes,
+ .write_bytes = mmio_write_bytes,
+ .read32 = mmio_read32,
+ .write32 = mmio_write32,
+};
+
+static int tpm_tis_probe(struct udevice *dev)
+{
+ struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(dev);
+ struct tpm_chip_priv *priv = dev_get_uclass_priv(dev);
+ int ret = 0;
+ fdt_addr_t ioaddr;
+ u64 sz;
+
+ ioaddr = dev_read_addr(dev);
+ if (ioaddr == FDT_ADDR_T_NONE)
+ return log_msg_ret("ioaddr", -EINVAL);
+
+ ret = dev_read_u64(dev, "reg", );
+ if (ret)
+ return -EINVAL;
+
+ drv_data->iobase = ioremap(ioaddr, sz);
+ log_debug("Remapped TPM2 base: 0x%llx size: 0x%llx\n", ioaddr, sz);
+ tpm_tis_ops_register(dev, _ops);
+ ret = tpm_tis_init(dev);
+ if (ret)
+ goto iounmap;
+
+ priv->pcr_count = drv_data->pcr_count;
+ priv->pcr_select_min = drv_data->pcr_select_min;
+ /*
+* Although the driver probably works with a TPMv1 our Kconfig
+* limits the driver to TPMv2 only
+*/
+ priv->version = TPM_V2;
+
+ return ret;
+iounmap:
+ iounmap(drv_data->iobase);
+ return -EINVAL;
+}
+
+static int tpm_tis_remove(struct udevice *dev)
+{
+ struct
[PATCH 1/6 v5] tpm2: Introduce TIS tpm core
There's a lot of code duplication in U-Boot right now. All the TPM TIS
compatible drivers we have at the moment have their own copy of a TIS
implementation.
So let's create a common layer which implements the core TIS functions.
Any driver added from now own, which is compatible with the TIS spec, will
only have to provide the underlying bus communication mechanisms.
Signed-off-by: Ilias Apalodimas
---
drivers/tpm/tpm2_tis_core.c | 463
drivers/tpm/tpm_tis.h | 128 ++
include/tpm-v2.h| 1 +
3 files changed, 592 insertions(+)
create mode 100644 drivers/tpm/tpm2_tis_core.c
diff --git a/drivers/tpm/tpm2_tis_core.c b/drivers/tpm/tpm2_tis_core.c
new file mode 100644
index ..ec8c730fe906
--- /dev/null
+++ b/drivers/tpm/tpm2_tis_core.c
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, Linaro Limited
+ *
+ * Based on the Linux TIS core interface and U-Boot original SPI TPM driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "tpm_tis.h"
+
+int tpm_tis_get_desc(struct udevice *dev, char *buf, int size)
+{
+ struct tpm_chip *chip = dev_get_priv(dev);
+
+ if (size < 80)
+ return -ENOSPC;
+
+ return snprintf(buf, size,
+ "%s v2.0: VendorID 0x%04x, DeviceID 0x%04x, RevisionID
0x%02x [%s]",
+ dev->name, chip->vend_dev & 0x,
+ chip->vend_dev >> 16, chip->rid,
+ (chip->is_open ? "open" : "closed"));
+}
+
+/**
+ * tpm_tis_check_locality - Check the current TPM locality
+ *
+ * @dev: TPM device
+ * @loc: locality
+ *
+ * Return: True if the tested locality matches
+ */
+static bool tpm_tis_check_locality(struct udevice *dev, int loc)
+{
+ struct tpm_chip *chip = dev_get_priv(dev);
+ struct tpm_tis_phy_ops *phy_ops = chip->phy_ops;
+ u8 locality;
+
+ phy_ops->read_bytes(dev, TPM_ACCESS(loc), 1, );
+ if ((locality & (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID |
+ TPM_ACCESS_REQUEST_USE)) ==
+ (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+ chip->locality = loc;
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * tpm_tis_request_locality - Request a locality from the TPM
+ *
+ * @dev: TPM device
+ * @loc: requested locality
+ *
+ * Return: 0 on success -1 on failure
+ */
+int tpm_tis_request_locality(struct udevice *dev, int loc)
+{
+ struct tpm_chip *chip = dev_get_priv(dev);
+ struct tpm_tis_phy_ops *phy_ops = chip->phy_ops;
+ u8 buf = TPM_ACCESS_REQUEST_USE;
+ unsigned long start, stop;
+
+ if (tpm_tis_check_locality(dev, loc))
+ return 0;
+
+ phy_ops->write_bytes(dev, TPM_ACCESS(loc), 1, );
+ start = get_timer(0);
+ stop = chip->timeout_a;
+ do {
+ if (tpm_tis_check_locality(dev, loc))
+ return 0;
+ mdelay(TPM_TIMEOUT_MS);
+ } while (get_timer(start) < stop);
+
+ return -1;
+}
+
+/**
+ * tpm_tis_status - Check the current device status
+ *
+ * @dev: TPM device
+ * @status: return value of status
+ *
+ * Return: 0 on success, negative on failure
+ */
+static int tpm_tis_status(struct udevice *dev, u8 *status)
+{
+ struct tpm_chip *chip = dev_get_priv(dev);
+ struct tpm_tis_phy_ops *phy_ops = chip->phy_ops;
+
+ if (chip->locality < 0)
+ return -EINVAL;
+
+ phy_ops->read_bytes(dev, TPM_STS(chip->locality), 1, status);
+
+ if ((*status & TPM_STS_READ_ZERO)) {
+ log_err("TPM returned invalid status\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
+ * tpm_tis_release_locality - Release the requested locality
+ *
+ * @dev: TPM device
+ * @loc: requested locality
+ *
+ * Return: 0 on success, negative on failure
+ */
+int tpm_tis_release_locality(struct udevice *dev, int loc)
+{
+ struct tpm_chip *chip = dev_get_priv(dev);
+ struct tpm_tis_phy_ops *phy_ops = chip->phy_ops;
+ u8 buf = TPM_ACCESS_ACTIVE_LOCALITY;
+ int ret;
+
+ if (chip->locality < 0)
+ return 0;
+
+ ret = phy_ops->write_bytes(dev, TPM_ACCESS(loc), 1, );
+ chip->locality = -1;
+
+ return ret;
+}
+
+/**
+ * tpm_tis_wait_for_stat - Wait for TPM to become ready
+ *
+ * @dev: TPM device
+ * @mask:mask to match
+ * @timeout: timeout for retries
+ * @status: current status
+ *
+ * Return: 0 on success, negative on failure
+ */
+static int tpm_tis_wait_for_stat(struct udevice *dev, u8 mask,
+unsigned long timeout, u8 *status)
+{
+ unsigned long start = get_timer(0);
+ unsigned long stop = timeout;
+ int ret;
+
+ do {
+ mdelay(TPM_TIMEOUT_MS);
+ ret = tpm_tis_status(dev, status);
+ if (ret)
+ return ret;
+
+
[PATCH 0/6 v5] TPM cleanups and MMIO driver
Hi! This is the update for [1]. Changes since v4: - renamed struct udevice *udev -> struct udevice *dev - added comments on struct tpm_tis_phy_ops - removed duplicate defines from tpm2_tis_spi driver (now in tpm_tis.h) - moved API function description for the .c to the .h file - added Reviewed-by tags from Simon and Heinrich Changes since v3: - Coverted SPI TPM to use the API as well - moved some log_info to log_debug - Added documentation on how to run QEMU and enabled TPM by default o arm qemu builds Changes since v2: - Add myself as a maintainer on TPM drivers Changes since v1: - split off the tis core code into a different file Ilias Apalodimas (6): tpm2: Introduce TIS tpm core tpm2: Add a TPMv2 MMIO TIS driver tpm: Use the new API on tpm2 spi driver configs: Enable tpmv2 mmio on qemu for arm/arm64 doc: qemu: Add instructions for swtpm usage MAINTAINERS: Add entry for TPM drivers [1] https://lore.kernel.org/u-boot/20211103150910.69732-1-ilias.apalodi...@linaro.org/ Ilias Apalodimas (6): tpm2: Introduce TIS tpm core tpm2: Add a TPMv2 MMIO TIS driver tpm: Use the new API on tpm2 spi driver configs: Enable tpmv2 mmio on qemu for arm/arm64 doc: qemu: Add instructions for swtpm usage MAINTAINERS: Add entry for TPM drivers MAINTAINERS | 5 + configs/qemu_arm64_defconfig | 2 + configs/qemu_arm_defconfig | 2 + doc/board/emulation/qemu-arm.rst | 25 ++ drivers/tpm/Kconfig | 9 + drivers/tpm/Makefile | 3 +- drivers/tpm/tpm2_tis_core.c | 463 +++ drivers/tpm/tpm2_tis_mmio.c | 152 ++ drivers/tpm/tpm2_tis_spi.c | 447 +++-- drivers/tpm/tpm_tis.h| 128 + include/tpm-v2.h | 1 + 11 files changed, 820 insertions(+), 417 deletions(-) create mode 100644 drivers/tpm/tpm2_tis_core.c create mode 100644 drivers/tpm/tpm2_tis_mmio.c -- 2.33.1
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On 11/5/21 17:12, Simon Glass wrote: Hi, On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: Hi Andre, Added Tom to Cc. On 05.11.21 11:04, Andre Przywara wrote: On Thu, 4 Nov 2021 20:02:41 -0600 Simon Glass wrote: Hi, On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: Hi Andre, On 05.11.21 00:11, Andre Przywara wrote: On Thu, 4 Nov 2021 11:37:57 +0100 Stefan Roese wrote: Hi Stefan, On 04.11.21 04:55, Samuel Holland wrote: This series hooks up the watchdog uclass to automatically register watchdog devices for use with sysreset, doing a bit of minor cleanup along the way. The goal is for this to replace the sunxi board-level non-DM reset_cpu() function. I was surprised to find that the wdt_reboot driver requires its own undocumented device tree node, which references the watchdog device by phandle. This is problematic for us, because sunxi-u-boot.dtsi file covers 20 different SoCs with varying watchdog node phandle names. So it would have required adding a -u-boot.dtsi file for each board. Hooking things up automatically makes sense to me; this is what Linux does. However, I put the code behind a new option to avoid surprises for other platforms. Changes in v3: - Move condition to wdt-uclass.c to fix build errors. - Include watchdog name in error message. Changes in v2: - Extend the "if SYSRESET" block to the end of the file. - Also make gpio_reboot_probe function static. - Rebase on top of 492ee6b8d0e7 (now handle all watchdogs). - Added patches 5-6 as an example of how the new option will be used. Samuel Holland (6): sysreset: Add uclass Kconfig dependency to drivers sysreset: Mark driver probe functions as static sysreset: watchdog: Move watchdog reference to plat data watchdog: Automatically register device with sysreset sunxi: Avoid duplicate reset_cpu with SYSRESET enabled sunxi: Use sysreset framework for poweroff/reset arch/arm/Kconfig | 3 +++ arch/arm/mach-sunxi/board.c | 2 ++ drivers/sysreset/Kconfig | 11 ++-- drivers/sysreset/sysreset_gpio.c | 2 +- drivers/sysreset/sysreset_resetctl.c | 2 +- drivers/sysreset/sysreset_syscon.c | 2 +- drivers/sysreset/sysreset_watchdog.c | 40 ++-- drivers/watchdog/wdt-uclass.c| 8 ++ include/sysreset.h | 10 +++ 9 files changed, 67 insertions(+), 13 deletions(-) Applied to u-boot-marvell Mmmh, why u-boot-marvell, Because I'm handling watchdog related changed since a few years and we did not create a specific subsystem repo for this and I'm usually using my "marvell" one for this. And fwiw, there's a few other cases like this. If it's too confusing, maybe we should just roll out a few more repositories, I think it's easier to do that now than pre-gitlab? and why did this end up already in master? Isn't that material for the next merge window? After all this changes quite a bit, for a lot of boards, and I did not have a closer look at the sunxi parts yet. I was hesitating also a bit. But since this patchset is on the list in v1 since over 2 months now (2021-08-21) I thought it was "ready" for inclusion now. We are at -rc1 and I think we still have enough time to fix any resulting problems in this release cycle. Why do we have the merge window then? This is clearly not a regression or general fix. AFAIU, we are a bit less strict here in U-Boot. Patches that were posted before the merge-window and skipped the review process (most likely because of lack of time) are often still integrated in the early rcX cycles. At least this is how I handle it usually. Tom, is my understanding here correct? Yes. We are not as strict as the kernel is about what can come in between rc1 and rc2 (and to a certain degree, post rc2). I leave things up to the discretion of the custodians. People tend of have less time to handle U-Boot changes than other stuff, so I try and be flexible in picking things up. Yes I agree, that should be plenty of time for people to review it. Well, if there would be people to review the sunxi parts :-( I am totally fine with the generic patches (as they have been reviewed), but the sunxi integration is somewhat risky. I was explicitly deprioritising that in my queue, as it really doesn't change, add or fix anything, it's mere refactoring, from the user's point of view. Do you see any specific issues? Patch 6/6 changes the config for all 157 Allwinner boards, so I think that deserves at least some testing, *before* merging it. I expect that Samuel did some testing. But still, I agree that it would be much better, if these patches - especially the Allwinner parts got more extensive testing. I will do as much testing now as possible, but I am not happy about that situation. Understood. Should we revert patch 6/6 for now?
[PATCH 1/1] watchdog: don't autostart watchdog on Sunxi boards
The Sunxi boards only support a 16 second watchdog timeout. This is too
short to boot Linux. The UEFI specification requires 300 seconds as
default timeout.
Change the default for CONFIG_WATCHDOG_AUTOSTART for ARCH_SUNXI.
Fixes: b147bd3607f8 ("sunxi: Enable watchdog timer support by default")
Signed-off-by: Heinrich Schuchardt
---
drivers/watchdog/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d306054a8c..1177f17fd8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -12,6 +12,7 @@ config WATCHDOG
config WATCHDOG_AUTOSTART
bool "Automatically start watchdog timer"
depends on WDT
+ default n if ARCH_SUNXI
default y
help
Automatically start watchdog timer and start servicing it during
--
2.32.0
Re: [PATCH] sf: Querying write-protect status before operating the flash
On Fri, Nov 5, 2021 at 10:47 PM wrote:
>
> Hi,
>
> On 6/22/21 8:21 AM, chao zeng wrote:
> > From: Chao Zeng
> >
> > When operating the write-protection flash,spi_flash_std_write() and
> > spi_flash_std_erase() would return wrong result.The flash is protected,
> > but write or erase the flash would show "OK".
> >
> > Check the flash write protection state if the write-protection has enbale
> > before operating the flash.
> >
> > Signed-off-by: Chao Zeng
> > ---
> >
> > drivers/mtd/spi/sf_probe.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> > index 3befbe91ca..f06e6b88bd 100644
> > --- a/drivers/mtd/spi/sf_probe.c
> > +++ b/drivers/mtd/spi/sf_probe.c
> > @@ -109,6 +109,11 @@ static int spi_flash_std_write(struct udevice *dev,
> > u32 offset, size_t len,
> > struct mtd_info *mtd = >mtd;
> > size_t retlen;
> >
> > + if (flash->flash_is_locked && flash->flash_is_locked(flash, offset,
> > len)) {
> > + debug("SF: Flash is locked\n");
> > + return -ENOPROTOOPT;
>
> Keep a debug message, but return 0 please. Writes or erases on protected areas
> are ignored by the flash, we should reflect that in the code.
Agreed this point, Chao are you fine to do this change while applying it?
Jagan.
[PATCH 10/11] mmc: fsl_esdhc_imx: replace most #ifdefs by IS_ENABLED()
From: Michael Walle
[ fsl_esdhc commit 52faec31827ec1a1837977e29c067424426634c5 ]
Make the code cleaner and drop the old-style #ifdef constructs where it is
possible.
Signed-off-by: Michael Walle
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 209 +---
include/fsl_esdhc_imx.h | 2 -
2 files changed, 100 insertions(+), 111 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 4c8d74a070..886a489777 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -182,15 +182,15 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct
mmc_data *data)
if (data) {
xfertyp |= XFERTYP_DPSEL;
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
- xfertyp |= XFERTYP_DMAEN;
-#endif
+ if (!IS_ENABLED(CONFIG_SYS_FSL_ESDHC_USE_PIO) &&
+ cmd->cmdidx != MMC_CMD_SEND_TUNING_BLOCK &&
+ cmd->cmdidx != MMC_CMD_SEND_TUNING_BLOCK_HS200)
+ xfertyp |= XFERTYP_DMAEN;
if (data->blocks > 1) {
xfertyp |= XFERTYP_MSBSEL;
xfertyp |= XFERTYP_BCEN;
-#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
- xfertyp |= XFERTYP_AC12EN;
-#endif
+ if (IS_ENABLED(CONFIG_SYS_FSL_ERRATUM_ESDHC111))
+ xfertyp |= XFERTYP_AC12EN;
}
if (data->flags & MMC_DATA_READ)
@@ -214,7 +214,6 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct
mmc_data *data)
return XFERTYP_CMD(cmd->cmdidx) | xfertyp;
}
-#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
/*
* PIO Read/Write Mode reduce the performace as DMA is not used in this mode.
*/
@@ -277,9 +276,7 @@ static void esdhc_pio_read_write(struct fsl_esdhc_priv
*priv,
}
}
}
-#endif
-#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
static void esdhc_setup_watermark_level(struct fsl_esdhc_priv *priv,
struct mmc_data *data)
{
@@ -299,7 +296,6 @@ static void esdhc_setup_watermark_level(struct
fsl_esdhc_priv *priv,
wml_value << 16);
}
}
-#endif
static void esdhc_setup_dma(struct fsl_esdhc_priv *priv, struct mmc_data *data)
{
@@ -342,11 +338,10 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
}
}
-#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
- esdhc_setup_watermark_level(priv, data);
-#else
- esdhc_setup_dma(priv, data);
-#endif
+ if (IS_ENABLED(CONFIG_SYS_FSL_ESDHC_USE_PIO))
+ esdhc_setup_watermark_level(priv, data);
+ else
+ esdhc_setup_dma(priv, data);
/* Calculate the timeout period for data transactions */
/*
@@ -379,14 +374,13 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
if (timeout < 0)
timeout = 0;
-#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
- if ((timeout == 4) || (timeout == 8) || (timeout == 12))
+ if (IS_ENABLED(CONFIG_SYS_FSL_ERRATUM_ESDHC_A001) &&
+ (timeout == 4 || timeout == 8 || timeout == 12))
timeout++;
-#endif
-#ifdef ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
- timeout = 0xE;
-#endif
+ if (IS_ENABLED(ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE))
+ timeout = 0xE;
+
esdhc_clrsetbits32(>sysctl, SYSCTL_TIMEOUT_MASK, timeout << 16);
return 0;
@@ -409,6 +403,11 @@ static inline void sd_swap_dma_buff(struct mmc_data *data)
}
}
}
+#else
+static inline void sd_swap_dma_buff(struct mmc_data *data)
+{
+ return;
+}
#endif
/*
@@ -425,10 +424,9 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
struct fsl_esdhc *regs = priv->esdhc_regs;
unsigned long start;
-#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
- if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
+ if (IS_ENABLED(CONFIG_SYS_FSL_ERRATUM_ESDHC111) &&
+ cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
return 0;
-#endif
esdhc_write32(>irqstat, -1);
@@ -526,42 +524,40 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
/* Wait until all of the blocks are transferred */
if (data) {
-#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
- esdhc_pio_read_write(priv, data);
-#else
- flags = DATA_COMPLETE;
- if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK) ||
- (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)) {
- flags = IRQSTAT_BRR;
+ if (IS_ENABLED(CONFIG_SYS_FSL_ESDHC_USE_PIO)) {
+ esdhc_pio_read_write(priv, data);
+ } else {
+ flags = DATA_COMPLETE;
+ if (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
+ cmd->cmdidx
[PATCH 09/11] mmc: fsl_esdhc_imx: simplify esdhc_setup_data()
From: Michael Walle
[ fsl_esdhc commit 7e48a028a42c111ba38a90b86e5f57dace980fa0 ]
First, we need the waterlevel setting for PIO mode only. Secondy, both DMA
setup code is identical for both directions, except for the data pointer.
Thus, unify them.
Signed-off-by: Michael Walle
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 89 ++---
1 file changed, 52 insertions(+), 37 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 3d65094f81..4c8d74a070 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -279,59 +279,74 @@ static void esdhc_pio_read_write(struct fsl_esdhc_priv
*priv,
}
#endif
-static int esdhc_setup_data(struct fsl_esdhc_priv *priv, struct mmc *mmc,
- struct mmc_data *data)
+#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
+static void esdhc_setup_watermark_level(struct fsl_esdhc_priv *priv,
+ struct mmc_data *data)
{
- int timeout;
- uint trans_bytes = data->blocksize * data->blocks;
struct fsl_esdhc *regs = priv->esdhc_regs;
- uint wml_value;
-
- wml_value = data->blocksize/4;
+ uint wml_value = data->blocksize / 4;
if (data->flags & MMC_DATA_READ) {
if (wml_value > WML_RD_WML_MAX)
wml_value = WML_RD_WML_MAX_VAL;
esdhc_clrsetbits32(>wml, WML_RD_WML_MASK, wml_value);
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
- priv->dma_addr = dma_map_single(data->dest, trans_bytes,
- mmc_get_dma_dir(data));
- if (upper_32_bits(priv->dma_addr))
- printf("Cannot use 64 bit addresses with SDMA\n");
- esdhc_write32(>dsaddr, lower_32_bits(priv->dma_addr));
-#endif
} else {
if (wml_value > WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
- if (priv->wp_enable) {
- if ((esdhc_read32(>prsstat) &
- PRSSTAT_WPSPL) == 0) {
- printf("\nThe SD card is locked. Can not write
to a locked card.\n\n");
- return -ETIMEDOUT;
- }
- } else {
-#if CONFIG_IS_ENABLED(DM_GPIO)
- if (dm_gpio_is_valid(>wp_gpio) &&
- dm_gpio_get_value(>wp_gpio)) {
- printf("\nThe SD card is locked. Can not write
to a locked card.\n\n");
- return -ETIMEDOUT;
- }
-#endif
- }
esdhc_clrsetbits32(>wml, WML_WR_WML_MASK,
- wml_value << 16);
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
- priv->dma_addr = dma_map_single((void *)data->src, trans_bytes,
- mmc_get_dma_dir(data));
- if (upper_32_bits(priv->dma_addr))
- printf("Cannot use 64 bit addresses with SDMA\n");
- esdhc_write32(>dsaddr, lower_32_bits(priv->dma_addr));
-#endif
+ wml_value << 16);
}
+}
+#endif
+static void esdhc_setup_dma(struct fsl_esdhc_priv *priv, struct mmc_data *data)
+{
+ uint trans_bytes = data->blocksize * data->blocks;
+ struct fsl_esdhc *regs = priv->esdhc_regs;
+ void *buf;
+
+ if (data->flags & MMC_DATA_WRITE)
+ buf = (void *)data->src;
+ else
+ buf = data->dest;
+
+ priv->dma_addr = dma_map_single(buf, trans_bytes,
+ mmc_get_dma_dir(data));
+ if (upper_32_bits(priv->dma_addr))
+ printf("Cannot use 64 bit addresses with SDMA\n");
+ esdhc_write32(>dsaddr, lower_32_bits(priv->dma_addr));
esdhc_write32(>blkattr, data->blocks << 16 | data->blocksize);
+}
+
+static int esdhc_setup_data(struct fsl_esdhc_priv *priv, struct mmc *mmc,
+ struct mmc_data *data)
+{
+ int timeout;
+ bool is_write = data->flags & MMC_DATA_WRITE;
+ struct fsl_esdhc *regs = priv->esdhc_regs;
+
+ if (is_write) {
+ if (priv->wp_enable && !(esdhc_read32(>prsstat) &
PRSSTAT_WPSPL)) {
+ printf("Cannot write to locked SD card.\n");
+ return -EINVAL;
+ } else {
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ if (dm_gpio_is_valid(>wp_gpio) &&
+ dm_gpio_get_value(>wp_gpio)) {
+ printf("Cannot write to locked SD card.\n");
+ return -EINVAL;
+ }
+#endif
+ }
+ }
+
+#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
+ esdhc_setup_watermark_level(priv, data);
+#else
+ esdhc_setup_dma(priv, data);
+#endif
/*
[PATCH 11/11] mmc: fsl_esdhc_imx: set sysctl register for clock initialization
From: Yangbo Lu [ fsl_esdhc commit 263ddfc3454ead3a988adef39b962479adce2b28 ] The initial clock setting should be through sysctl register only, while the mmc_set_clock() will call mmc_set_ios() introduce other configurations like bus width, mode, and so on. Signed-off-by: Yangbo Lu Reviewed-by: Jaehoon Chung Signed-off-by: Sean Anderson --- drivers/mmc/fsl_esdhc_imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index 886a489777..fc92ac3826 100644 --- a/drivers/mmc/fsl_esdhc_imx.c +++ b/drivers/mmc/fsl_esdhc_imx.c @@ -1022,7 +1022,7 @@ static int esdhc_init_common(struct fsl_esdhc_priv *priv, struct mmc *mmc) #endif /* Set the initial clock speed */ - mmc_set_clock(mmc, 40, MMC_CLK_ENABLE); + set_sysctl(priv, mmc, 40); /* Disable the BRR and BWR bits in IRQSTAT */ esdhc_clrbits32(>irqstaten, IRQSTATEN_BRR | IRQSTATEN_BWR); -- 2.25.1
[PATCH 08/11] mmc: fsl_esdhc_imx: use dma-mapping API
From: Michael Walle
[ fsl_esdhc commit b1ba1460a445bcc67972a617625d0349e4f22b31 ]
Use the dma_{map,unmap}_single() calls. These will take care of the
flushing and invalidation of caches.
Signed-off-by: Michael Walle
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 50 +++--
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 7c070ed1c2..3d65094f81 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#ifndef ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
#ifdef CONFIG_FSL_USDHC
@@ -171,6 +172,7 @@ struct fsl_esdhc_priv {
struct gpio_desc cd_gpio;
struct gpio_desc wp_gpio;
#endif
+ dma_addr_t dma_addr;
};
/* Return the XFERTYP flags for a given command and data packet */
@@ -281,8 +283,8 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
struct mmc_data *data)
{
int timeout;
+ uint trans_bytes = data->blocksize * data->blocks;
struct fsl_esdhc *regs = priv->esdhc_regs;
- dma_addr_t addr;
uint wml_value;
wml_value = data->blocksize/4;
@@ -293,17 +295,13 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
esdhc_clrsetbits32(>wml, WML_RD_WML_MASK, wml_value);
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
- addr = virt_to_phys((void *)(data->dest));
- if (upper_32_bits(addr))
+ priv->dma_addr = dma_map_single(data->dest, trans_bytes,
+ mmc_get_dma_dir(data));
+ if (upper_32_bits(priv->dma_addr))
printf("Cannot use 64 bit addresses with SDMA\n");
- esdhc_write32(>dsaddr, lower_32_bits(addr));
+ esdhc_write32(>dsaddr, lower_32_bits(priv->dma_addr));
#endif
} else {
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
- flush_dcache_range((ulong)data->src,
- (ulong)data->src+data->blocks
-*data->blocksize);
-#endif
if (wml_value > WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
if (priv->wp_enable) {
@@ -325,10 +323,11 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
esdhc_clrsetbits32(>wml, WML_WR_WML_MASK,
wml_value << 16);
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
- addr = virt_to_phys((void *)(data->src));
- if (upper_32_bits(addr))
+ priv->dma_addr = dma_map_single((void *)data->src, trans_bytes,
+ mmc_get_dma_dir(data));
+ if (upper_32_bits(priv->dma_addr))
printf("Cannot use 64 bit addresses with SDMA\n");
- esdhc_write32(>dsaddr, lower_32_bits(addr));
+ esdhc_write32(>dsaddr, lower_32_bits(priv->dma_addr));
#endif
}
@@ -378,23 +377,6 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
return 0;
}
-static void check_and_invalidate_dcache_range
- (struct mmc_cmd *cmd,
-struct mmc_data *data) {
- unsigned start = 0;
- unsigned end = 0;
- unsigned size = roundup(ARCH_DMA_MINALIGN,
- data->blocks*data->blocksize);
- dma_addr_t addr;
-
- addr = virt_to_phys((void *)(data->dest));
- if (upper_32_bits(addr))
- printf("Cannot use 64 bit addresses with SDMA\n");
- start = lower_32_bits(addr);
- end = start + size;
- invalidate_dcache_range(start, end);
-}
-
#ifdef CONFIG_MCF5441x
/*
* Swaps 32-bit words to little-endian byte order.
@@ -450,9 +432,6 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
err = esdhc_setup_data(priv, mmc, data);
if(err)
return err;
-
- if (data->flags & MMC_DATA_READ)
- check_and_invalidate_dcache_range(cmd, data);
}
/* Figure out the transfer arguments */
@@ -560,12 +539,13 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
* cache-fill during the DMA operations such as the
* speculative pre-fetching etc.
*/
- if (data->flags & MMC_DATA_READ) {
- check_and_invalidate_dcache_range(cmd, data);
+ dma_unmap_single(priv->dma_addr,
+data->blocks * data->blocksize,
+mmc_get_dma_dir(data));
#ifdef CONFIG_MCF5441x
+ if (data->flags & MMC_DATA_READ)
sd_swap_dma_buff(data);
#endif
-
[PATCH 06/11] mmc: fsl_esdhc_imx: fix mmc->clock with actual clock
[ fsl_esdhc commit 30f6444d024a74ee48aa6969c1531aecd3c59deb ] Fix mmc->clock with actual clock which is divided by the controller, and record it with priv->clock. Signed-off-by: Yangbo Lu Signed-off-by: Sean Anderson --- drivers/mmc/fsl_esdhc_imx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index a3cd9e5be1..dc71e39f8e 100644 --- a/drivers/mmc/fsl_esdhc_imx.c +++ b/drivers/mmc/fsl_esdhc_imx.c @@ -665,6 +665,7 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, struct mmc *mmc, uint clock) esdhc_setbits32(>sysctl, SYSCTL_PEREN | SYSCTL_CKEN); #endif + mmc->clock = sdhc_clk / pre_div / div; priv->clock = clock; } -- 2.25.1
[PATCH 07/11] mmc: fsl_esdhc_imx: simplify 64bit check for SDMA transfers
From: Michael Walle
[ fsl_esdhc commit da86e8cfcb03ed5c1d8e0718bc8bc8583e60ced8 ]
SDMA can only do DMA with 32 bit addresses. This is true for all
architectures (just doesn't apply to 32 bit ones). Simplify the code and
remove unnecessary CONFIG_FSL_LAYERSCAPE.
Also make the error message more concise.
Signed-off-by: Michael Walle
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 33 ++---
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index dc71e39f8e..7c070ed1c2 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -282,10 +282,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
{
int timeout;
struct fsl_esdhc *regs = priv->esdhc_regs;
-#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
|| \
- defined(CONFIG_IMX8ULP)
dma_addr_t addr;
-#endif
uint wml_value;
wml_value = data->blocksize/4;
@@ -296,16 +293,10 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
esdhc_clrsetbits32(>wml, WML_RD_WML_MASK, wml_value);
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
-#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
|| \
- defined(CONFIG_IMX8ULP)
addr = virt_to_phys((void *)(data->dest));
if (upper_32_bits(addr))
- printf("Error found for upper 32 bits\n");
- else
- esdhc_write32(>dsaddr, lower_32_bits(addr));
-#else
- esdhc_write32(>dsaddr, (u32)data->dest);
-#endif
+ printf("Cannot use 64 bit addresses with SDMA\n");
+ esdhc_write32(>dsaddr, lower_32_bits(addr));
#endif
} else {
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
@@ -334,16 +325,10 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
esdhc_clrsetbits32(>wml, WML_WR_WML_MASK,
wml_value << 16);
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
-#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
|| \
- defined(CONFIG_IMX8ULP)
addr = virt_to_phys((void *)(data->src));
if (upper_32_bits(addr))
- printf("Error found for upper 32 bits\n");
- else
- esdhc_write32(>dsaddr, lower_32_bits(addr));
-#else
- esdhc_write32(>dsaddr, (u32)data->src);
-#endif
+ printf("Cannot use 64 bit addresses with SDMA\n");
+ esdhc_write32(>dsaddr, lower_32_bits(addr));
#endif
}
@@ -400,18 +385,12 @@ static void check_and_invalidate_dcache_range
unsigned end = 0;
unsigned size = roundup(ARCH_DMA_MINALIGN,
data->blocks*data->blocksize);
-#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
|| \
- defined(CONFIG_IMX8ULP)
dma_addr_t addr;
addr = virt_to_phys((void *)(data->dest));
if (upper_32_bits(addr))
- printf("Error found for upper 32 bits\n");
- else
- start = lower_32_bits(addr);
-#else
- start = (unsigned)data->dest;
-#endif
+ printf("Cannot use 64 bit addresses with SDMA\n");
+ start = lower_32_bits(addr);
end = start + size;
invalidate_dcache_range(start, end);
}
--
2.25.1
[PATCH 05/11] mmc: fsl_esdhc_imx: drop redundant code for non-removable feature
From: Yangbo Lu
[ fsl_esdhc commit commit 08197cb8dff7cd097ab07a325093043c39d19bbd ]
Drop redundant code for non-removable feature. "non-removable" property
has been read in mmc_of_parse().
Signed-off-by: Yangbo Lu
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index d3daf4db59..a3cd9e5be1 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -130,7 +130,6 @@ struct esdhc_soc_data {
* @mmc: mmc
* Following is used when Driver Model is enabled for MMC
* @dev: pointer for the device
- * @non_removable: 0: removable; 1: non-removable
* @broken_cd: 0: use GPIO for card detect; 1: Do not use GPIO for card detect
* @wp_enable: 1: enable checking wp; 0: no check
* @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
@@ -154,7 +153,6 @@ struct fsl_esdhc_priv {
struct mmc *mmc;
#endif
struct udevice *dev;
- int non_removable;
int broken_cd;
int wp_enable;
int vs18_enable;
@@ -1083,9 +1081,6 @@ static int esdhc_getcd_common(struct fsl_esdhc_priv *priv)
#endif
#if CONFIG_IS_ENABLED(DM_MMC)
- if (priv->non_removable)
- return 1;
-
if (priv->broken_cd)
return 1;
#if CONFIG_IS_ENABLED(DM_GPIO)
@@ -1412,25 +1407,18 @@ static int fsl_esdhc_of_to_plat(struct udevice *dev)
if (dev_read_bool(dev, "broken-cd"))
priv->broken_cd = 1;
- if (dev_read_bool(dev, "non-removable")) {
- priv->non_removable = 1;
-} else {
- priv->non_removable = 0;
-#if CONFIG_IS_ENABLED(DM_GPIO)
- gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
-GPIOD_IS_IN);
-#endif
- }
-
if (dev_read_prop(dev, "fsl,wp-controller", NULL)) {
priv->wp_enable = 1;
} else {
priv->wp_enable = 0;
+ }
+
#if CONFIG_IS_ENABLED(DM_GPIO)
- gpio_request_by_name(dev, "wp-gpios", 0, >wp_gpio,
- GPIOD_IS_IN);
+ gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
+GPIOD_IS_IN);
+ gpio_request_by_name(dev, "wp-gpios", 0, >wp_gpio,
+GPIOD_IS_IN);
#endif
- }
priv->vs18_enable = 0;
@@ -1564,8 +1552,12 @@ static int fsl_esdhc_probe(struct udevice *dev)
static int fsl_esdhc_get_cd(struct udevice *dev)
{
+ struct fsl_esdhc_plat *plat = dev_get_plat(dev);
struct fsl_esdhc_priv *priv = dev_get_priv(dev);
+ if (plat->cfg.host_caps & MMC_CAP_NONREMOVABLE)
+ return 1;
+
return esdhc_getcd_common(priv);
}
--
2.25.1
[PATCH 04/11] mmc: fsl_esdhc_imx: clean up bus width configuration code
[ fsl_esdhc commit 07bae1de382723b94244096953b05225572728cd ]
This patch is to clean up bus width setting code.
- For DM_MMC, remove getting "bus-width" from device tree.
This has been done in mmc_of_parse().
- For non-DM_MMC, move bus width configuration from fsl_esdhc_init()
to fsl_esdhc_initialize() which is non-DM_MMC specific.
And fix up bus width configuration to support only 1-bit, 4-bit,
or 8-bit. Keep using 8-bit if it's not set because many platforms
use driver without providing max bus width.
- Remove bus_width member from fsl_esdhc_priv structure.
Signed-off-by: Yangbo Lu
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 80 +++--
1 file changed, 23 insertions(+), 57 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index b91dda27f9..d3daf4db59 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -126,7 +126,6 @@ struct esdhc_soc_data {
*
* @esdhc_regs: registers of the sdhc controller
* @sdhc_clk: Current clk of the sdhc controller
- * @bus_width: bus width, 1bit, 4bit or 8bit
* @cfg: mmc config
* @mmc: mmc
* Following is used when Driver Model is enabled for MMC
@@ -151,7 +150,6 @@ struct fsl_esdhc_priv {
struct clk per_clk;
unsigned int clock;
unsigned int mode;
- unsigned int bus_width;
#if !CONFIG_IS_ENABLED(DM_MMC)
struct mmc *mmc;
#endif
@@ -1232,31 +1230,13 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
#if !CONFIG_IS_ENABLED(DM_MMC)
cfg->ops = _ops;
#endif
- if (priv->bus_width == 8)
- cfg->host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
- else if (priv->bus_width == 4)
- cfg->host_caps = MMC_MODE_4BIT;
-
- cfg->host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
#ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
cfg->host_caps |= MMC_MODE_DDR_52MHz;
#endif
- if (priv->bus_width > 0) {
- if (priv->bus_width < 8)
- cfg->host_caps &= ~MMC_MODE_8BIT;
- if (priv->bus_width < 4)
- cfg->host_caps &= ~MMC_MODE_4BIT;
- }
-
if (caps & HOSTCAPBLT_HSS)
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
-#ifdef CONFIG_ESDHC_DETECT_8_BIT_QUIRK
- if (CONFIG_ESDHC_DETECT_8_BIT_QUIRK)
- cfg->host_caps &= ~MMC_MODE_8BIT;
-#endif
-
cfg->host_caps |= priv->caps;
cfg->f_min = 40;
@@ -1294,25 +1274,11 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
}
#if !CONFIG_IS_ENABLED(DM_MMC)
-static int fsl_esdhc_cfg_to_priv(struct fsl_esdhc_cfg *cfg,
-struct fsl_esdhc_priv *priv)
-{
- if (!cfg || !priv)
- return -EINVAL;
-
- priv->esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);
- priv->bus_width = cfg->max_bus_width;
- priv->sdhc_clk = cfg->sdhc_clk;
- priv->wp_enable = cfg->wp_enable;
- priv->vs18_enable = cfg->vs18_enable;
-
- return 0;
-};
-
int fsl_esdhc_initialize(struct bd_info *bis, struct fsl_esdhc_cfg *cfg)
{
struct fsl_esdhc_plat *plat;
struct fsl_esdhc_priv *priv;
+ struct mmc_config *mmc_cfg;
struct mmc *mmc;
int ret;
@@ -1328,14 +1294,30 @@ int fsl_esdhc_initialize(struct bd_info *bis, struct
fsl_esdhc_cfg *cfg)
return -ENOMEM;
}
- ret = fsl_esdhc_cfg_to_priv(cfg, priv);
- if (ret) {
- debug("%s xlate failure\n", __func__);
- free(plat);
- free(priv);
- return ret;
+ priv->esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);
+ priv->sdhc_clk = cfg->sdhc_clk;
+ priv->wp_enable = cfg->wp_enable;
+
+ mmc_cfg = >cfg;
+
+ if (cfg->max_bus_width == 8) {
+ mmc_cfg->host_caps |= MMC_MODE_1BIT | MMC_MODE_4BIT |
+ MMC_MODE_8BIT;
+ } else if (cfg->max_bus_width == 4) {
+ mmc_cfg->host_caps |= MMC_MODE_1BIT | MMC_MODE_4BIT;
+ } else if (cfg->max_bus_width == 1) {
+ mmc_cfg->host_caps |= MMC_MODE_1BIT;
+ } else {
+ mmc_cfg->host_caps |= MMC_MODE_1BIT | MMC_MODE_4BIT |
+ MMC_MODE_8BIT;
+ printf("No max bus width provided. Assume 8-bit supported.\n");
}
+#ifdef CONFIG_ESDHC_DETECT_8_BIT_QUIRK
+ if (CONFIG_ESDHC_DETECT_8_BIT_QUIRK)
+ mmc_cfg->host_caps &= ~MMC_MODE_8BIT;
+#endif
+
ret = fsl_esdhc_init(priv, plat);
if (ret) {
debug("%s init failure\n", __func__);
@@ -1416,14 +1398,6 @@ static int fsl_esdhc_of_to_plat(struct udevice *dev)
priv->dev = dev;
priv->mode = -1;
- val = dev_read_u32_default(dev, "bus-width", -1);
- if (val == 8)
- priv->bus_width = 8;
- else if (val ==
[PATCH 03/11] mmc: fsl_esdhc_imx: fix voltage validation
[ fsl_esdhc commit 5b05fc0310cd933acf76ee661577c6b07a95e684 ]
Voltage validation should be done by CMD8. Current comparison between
mmc_cfg voltages and host voltage capabilities is meaningless.
So drop current comparison and let voltage validation is through CMD8.
Signed-off-by: Yangbo Lu
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 35 +--
include/fsl_esdhc_imx.h | 12 ++--
2 files changed, 19 insertions(+), 28 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 40886f37aa..b91dda27f9 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1164,7 +1164,7 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
{
struct mmc_config *cfg;
struct fsl_esdhc *regs;
- u32 caps, voltage_caps;
+ u32 caps;
int ret;
if (!priv)
@@ -1203,9 +1203,7 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
memset(cfg, '\0', sizeof(*cfg));
#endif
- voltage_caps = 0;
caps = esdhc_read32(>hostcapblt);
-
#ifdef CONFIG_MCF5441x
/*
* MCF5441x RM declares in more points that sdhc clock speed must
@@ -1216,31 +1214,24 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC135
- caps = caps & ~(ESDHC_HOSTCAPBLT_SRS |
- ESDHC_HOSTCAPBLT_VS18 | ESDHC_HOSTCAPBLT_VS30);
+ caps &= ~(HOSTCAPBLT_SRS | HOSTCAPBLT_VS18 | HOSTCAPBLT_VS30);
#endif
- if (caps & ESDHC_HOSTCAPBLT_VS18)
- voltage_caps |= MMC_VDD_165_195;
- if (caps & ESDHC_HOSTCAPBLT_VS30)
- voltage_caps |= MMC_VDD_29_30 | MMC_VDD_30_31;
- if (caps & ESDHC_HOSTCAPBLT_VS33)
- voltage_caps |= MMC_VDD_32_33 | MMC_VDD_33_34;
+#ifdef CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
+ caps |= HOSTCAPBLT_VS33;
+#endif
+
+ if (caps & HOSTCAPBLT_VS18)
+ cfg->voltages |= MMC_VDD_165_195;
+ if (caps & HOSTCAPBLT_VS30)
+ cfg->voltages |= MMC_VDD_29_30 | MMC_VDD_30_31;
+ if (caps & HOSTCAPBLT_VS33)
+ cfg->voltages |= MMC_VDD_32_33 | MMC_VDD_33_34;
cfg->name = "FSL_SDHC";
#if !CONFIG_IS_ENABLED(DM_MMC)
cfg->ops = _ops;
#endif
-#ifdef CONFIG_SYS_SD_VOLTAGE
- cfg->voltages = CONFIG_SYS_SD_VOLTAGE;
-#else
- cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
-#endif
- if ((cfg->voltages & voltage_caps) == 0) {
- printf("voltage not supported by controller\n");
- return -1;
- }
-
if (priv->bus_width == 8)
cfg->host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
else if (priv->bus_width == 4)
@@ -1258,7 +1249,7 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
cfg->host_caps &= ~MMC_MODE_4BIT;
}
- if (caps & ESDHC_HOSTCAPBLT_HSS)
+ if (caps & HOSTCAPBLT_HSS)
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
#ifdef CONFIG_ESDHC_DETECT_8_BIT_QUIRK
diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h
index 45ed635a77..1529b8bba3 100644
--- a/include/fsl_esdhc_imx.h
+++ b/include/fsl_esdhc_imx.h
@@ -164,12 +164,12 @@
#define BLKATTR_SIZE(x)(x & 0x1fff)
#define MAX_BLK_CNT0x7fff /* so malloc will have enough room with 32M */
-#define ESDHC_HOSTCAPBLT_VS18 0x0400
-#define ESDHC_HOSTCAPBLT_VS30 0x0200
-#define ESDHC_HOSTCAPBLT_VS33 0x0100
-#define ESDHC_HOSTCAPBLT_SRS 0x0080
-#define ESDHC_HOSTCAPBLT_DMAS 0x0040
-#define ESDHC_HOSTCAPBLT_HSS 0x0020
+#define HOSTCAPBLT_VS180x0400
+#define HOSTCAPBLT_VS300x0200
+#define HOSTCAPBLT_VS330x0100
+#define HOSTCAPBLT_SRS 0x0080
+#define HOSTCAPBLT_DMAS0x0040
+#define HOSTCAPBLT_HSS 0x0020
#define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
--
2.25.1
[PATCH 02/11] mmc: fsl_esdhc_imx: remove redundant DM_MMC checking
[ fsl_esdhc commit 2913926f3b3dec282f8773e3c02377c9600d8267 ]
Remove redundant DM_MMC checking which is already in DM_MMC conditional
compile block.
Signed-off-by: Yangbo Lu
Signed-off-by: Sean Anderson
---
drivers/mmc/fsl_esdhc_imx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 0a7f7e61cb..40886f37aa 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1605,7 +1605,6 @@ static int fsl_esdhc_probe(struct udevice *dev)
return esdhc_init_common(priv, mmc);
}
-#if CONFIG_IS_ENABLED(DM_MMC)
static int fsl_esdhc_get_cd(struct udevice *dev)
{
struct fsl_esdhc_priv *priv = dev_get_priv(dev);
@@ -1671,7 +1670,6 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
#endif
.wait_dat0 = fsl_esdhc_wait_dat0,
};
-#endif
static struct esdhc_soc_data usdhc_imx7d_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
--
2.25.1
[PATCH 01/11] mmc: fsl_esdhc_imx: make BLK as hard requirement of DM_MMC
[ fsl_esdhc commit 41dec2fe99512e941261594f522b2e7d485c314b ]
U-boot prefers DM_MMC + BLK for MMC. Now eSDHC driver has already
support it, so let's force to use it.
- Drop non-BLK support for DM_MMC introduced by below patch.
66fa035 mmc: fsl_esdhc: fix probe issue without CONFIG_BLK enabled
- Support only DM_MMC + BLK (assuming BLK is always enabled for DM_MMC).
- Use DM_MMC instead of BLK for conditional compile.
Signed-off-by: Yangbo Lu
Signed-off-by: Sean Anderson
---
drivers/mmc/Kconfig | 2 ++
drivers/mmc/fsl_esdhc_imx.c | 33 +
2 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 1569e8c44a..313244682a 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -790,6 +790,7 @@ endif
config FSL_ESDHC
bool "Freescale/NXP eSDHC controller support"
+ depends on BLK
help
This selects support for the eSDHC (Enhanced Secure Digital Host
Controller) found on numerous Freescale/NXP SoCs.
@@ -826,6 +827,7 @@ config FSL_ESDHC_VS33_NOT_SUPPORT
config FSL_ESDHC_IMX
bool "Freescale/NXP i.MX eSDHC controller support"
+ depends on BLK
help
This selects support for the i.MX eSDHC (Enhanced Secure Digital Host
Controller) found on numerous Freescale/NXP SoCs.
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index aabf39535f..0a7f7e61cb 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -39,10 +39,6 @@
#include
#include
-#if !CONFIG_IS_ENABLED(BLK)
-#include "mmc_private.h"
-#endif
-
#ifndef ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
#ifdef CONFIG_FSL_USDHC
#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE 1
@@ -58,7 +54,6 @@ DECLARE_GLOBAL_DATA_PTR;
IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
IRQSTATEN_DINT)
#define MAX_TUNING_LOOP 40
-#define ESDHC_DRIVER_STAGE_VALUE 0x
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
@@ -157,7 +152,7 @@ struct fsl_esdhc_priv {
unsigned int clock;
unsigned int mode;
unsigned int bus_width;
-#if !CONFIG_IS_ENABLED(BLK)
+#if !CONFIG_IS_ENABLED(DM_MMC)
struct mmc *mmc;
#endif
struct udevice *dev;
@@ -1506,9 +1501,6 @@ static int fsl_esdhc_probe(struct udevice *dev)
struct esdhc_soc_data *data =
(struct esdhc_soc_data *)dev_get_driver_data(dev);
struct mmc *mmc;
-#if !CONFIG_IS_ENABLED(BLK)
- struct blk_desc *bdesc;
-#endif
int ret;
#if CONFIG_IS_ENABLED(OF_PLATDATA)
@@ -1607,25 +1599,6 @@ static int fsl_esdhc_probe(struct udevice *dev)
mmc = >mmc;
mmc->cfg = >cfg;
mmc->dev = dev;
-#if !CONFIG_IS_ENABLED(BLK)
- mmc->priv = priv;
-
- /* Setup dsr related values */
- mmc->dsr_imp = 0;
- mmc->dsr = ESDHC_DRIVER_STAGE_VALUE;
- /* Setup the universal parts of the block interface just once */
- bdesc = mmc_get_blk_desc(mmc);
- bdesc->if_type = IF_TYPE_MMC;
- bdesc->removable = 1;
- bdesc->devnum = mmc_get_next_devnum();
- bdesc->block_read = mmc_bread;
- bdesc->block_write = mmc_bwrite;
- bdesc->block_erase = mmc_berase;
-
- /* setup initial part type */
- bdesc->part_type = mmc->cfg->part_type;
- mmc_list_add(mmc);
-#endif
upriv->mmc = mmc;
@@ -1730,14 +1703,12 @@ static const struct udevice_id fsl_esdhc_ids[] = {
{ /* sentinel */ }
};
-#if CONFIG_IS_ENABLED(BLK)
static int fsl_esdhc_bind(struct udevice *dev)
{
struct fsl_esdhc_plat *plat = dev_get_plat(dev);
return mmc_bind(dev, >mmc, >cfg);
}
-#endif
U_BOOT_DRIVER(fsl_esdhc) = {
.name = "fsl_esdhc",
@@ -1745,9 +1716,7 @@ U_BOOT_DRIVER(fsl_esdhc) = {
.of_match = fsl_esdhc_ids,
.of_to_plat = fsl_esdhc_of_to_plat,
.ops= _esdhc_ops,
-#if CONFIG_IS_ENABLED(BLK)
.bind = fsl_esdhc_bind,
-#endif
.probe = fsl_esdhc_probe,
.plat_auto = sizeof(struct fsl_esdhc_plat),
.priv_auto = sizeof(struct fsl_esdhc_priv),
--
2.25.1
[PATCH 00/11] fsl_esdhc_imx: port several patches from fsl_esdhc
This series ports some of the patches from fsl_esdhc to fsl_esdhc_imx.
Because these drivers share a common lineage, many of these patches
apply with minor changes. For each one, I have noted the originating
commit in the style of linux stable backports.
In fa33d20749 ("mmc: split fsl_esdhc driver for i.MX"), Yangbo says
> For the two series processors, the eSDHCs are becoming more and more different
However, these drivers are still extremely similar; the differences
between them are not major. However, NXP has not done a good job of
porting patches which apply to both drivers. This causes the
fsl_esdhc_imx driver to rot, as the fsl_esdhc gets more general fixes.
For this reason, I think that the fsl_esdhc_imx driver should be removed
unless NXP can commit to creating series like this which port patches
which apply to both drivers.
Michael Walle (4):
mmc: fsl_esdhc_imx: simplify 64bit check for SDMA transfers
mmc: fsl_esdhc_imx: use dma-mapping API
mmc: fsl_esdhc_imx: simplify esdhc_setup_data()
mmc: fsl_esdhc_imx: replace most #ifdefs by IS_ENABLED()
Sean Anderson (5):
mmc: fsl_esdhc_imx: make BLK as hard requirement of DM_MMC
mmc: fsl_esdhc_imx: remove redundant DM_MMC checking
mmc: fsl_esdhc_imx: fix voltage validation
mmc: fsl_esdhc_imx: clean up bus width configuration code
mmc: fsl_esdhc_imx: fix mmc->clock with actual clock
Yangbo Lu (2):
mmc: fsl_esdhc_imx: drop redundant code for non-removable feature
mmc: fsl_esdhc_imx: set sysctl register for clock initialization
drivers/mmc/Kconfig | 2 +
drivers/mmc/fsl_esdhc_imx.c | 484 ++--
include/fsl_esdhc_imx.h | 14 +-
3 files changed, 191 insertions(+), 309 deletions(-)
--
2.25.1
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
) to signal Hi François, On Fri, 5 Nov 2021 at 10:31, François Ozog wrote: > > Hi Simon, > > Le ven. 5 nov. 2021 à 17:12, Simon Glass a écrit : >> >> Hi François, >> >> On Fri, 5 Nov 2021 at 02:27, François Ozog wrote: >> > >> > >> > >> > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: >> >> >> >> Hi François, >> >> >> >> On Tue, 2 Nov 2021 at 10:03, François Ozog >> >> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: >> >> >> >> >> >> Hi François, >> >> >> >> >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog >> >> >> wrote: >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > this seems a great endeavor. I'd like to better understand the scope >> >> >> > of it. >> >> >> > >> >> >> > Is it to be used as part of what could become a U-Boot entry ABI >> >> >> > scheme? By that I mean giving some fixed aspects >> >> >> > to U-Boot entry while letting boards to have flexibility (say for >> >> >> > instance that the first 5 architecture ABI >> >> >> > parameter registers are reserved for U-Boot), and the Passage is >> >> >> > about specifying either those reserved registers >> >> >> > or one of them? >> >> >> >> >> >> The goal is to provide a standard entry scheme for all firmware >> >> >> binaries. Whether it achieves that (or can with some mods) is up for >> >> >> discussion. >> >> >> >> >> > If you say >> >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware >> >> > information passing facility which would be part of all firmware ABIs >> >> > (as the projects decide to define their own ABI) it looks good. >> >> > but If you say >> >> >> >> It is an ABI to be adopted by U-Boot but also other firmware. For >> >> example, if TF-A calls U-Boot it should use standard passage. If >> >> U-Boot calls TF-A or Optee it should use standard passage. >> >> >> >> > b) define a standard entry scheme (register map, processor state, MMU >> >> > state, SMMU state, GIC state...) that does not look realistic. >> >> >> >> No I don't mean that. This data structure could be used in any state, >> >> so long as the two registers are set correctly. >> >> >> >> > I think you mean a) but just want to be sure. >> >> >> >> Yes I think so. >> >> >> >> >> >> >> >> Re the registers, do you think we need 5? >> >> >> >> >> >> >> I don't :-) >> >> >> >> >> > >> >> >> > Thinking entry ABI, here is what I observed on Arm: >> >> >> > >> >> >> > Linux has two entry ABIs: >> >> >> > - plain: x0 = dtb; >> >> >> > command line = dtb:/chosen/bootargs; initrd = >> >> >> > dtb:/chosen/linux,initrd-* >> >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> >> >> >dtb = EFI_UUID config table; initrd = >> >> >> > efi:> >> >> > image_protocol::load_options >> >> >> > >> >> >> > U-Boot (proper) has plenty of schemes: >> >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is >> >> >> > bad in itself), or other registers >> >> >> > - additional information passing: board specific register scheme, >> >> >> > SMC calls >> >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be >> >> >> > launched by Videocore firmware >> >> >> > >> >> >> > Based on all the above, I would tend to think that RPI scheme is a >> >> >> > good idea but also >> >> >> > shall not prevent additional schemes for the boards. >> >> >> >> >> >> I was not actually considering Linux since I believe/assume its entry >> >> >> scheme is fixed and not up for discussion. >> >> >> >> >> >> I also did not think about the EFI case. As I understand it we cannot >> >> >> touch it as it is used by UEFI today. Maybe it is even in the >> >> >> standard? >> >> > >> >> > It is in the spec and we are making it evolve, or its understanding >> >> > evolve (jurisprudence) for instance on initrd standard handling. >> >> >> >> Well perhaps we could merge it with standard passage. But EFI is not >> >> going to want to use a bloblist, it will want to use a HOB. >> >> >> >> >> >> >> >> >> >> >> Really I am hoping we can start afresh...? >> >> >> >> >> >> > >> >> >> > What about a U-Boot Arm entry ABI like: >> >> >> > - plain: x0=dtb, x1=, x2-x5 = , other >> >> >> > registers are per platform, SMC calls allowed too >> >> >> >> >> >> Hmm we don't actually need the dtb as it is available in the bloblist. >> >> > >> >> > If you don't have x0=dtb, then you will not be able to use U-Boot on >> >> > RPI4. >> >> > Unless you want to redo everything the RPI firmware is doing. >> >> >> >> That's right, RPI cannot support standard passage. It is not >> >> open-source firmware so it isn't really relevant to this discussion. >> >> It will just do what it does and have limited functionality, with >> >> work-arounds to deal with the pain, as one might expect. >> >> >> > So you are seeing two "all-or-nothing" options: >> > : U-Boot entry is board specific as it is today >> > : A new form where the only parameter is a head of bloblist, >> > one of those blobs contain a DT >>
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
On Fri, 5 Nov 2021 10:12:11 -0600 Simon Glass wrote: Hi, > On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: > > > > On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: > > > Hi Andre, > > > > > > Added Tom to Cc. > > > > > > On 05.11.21 11:04, Andre Przywara wrote: > > > > On Thu, 4 Nov 2021 20:02:41 -0600 > > > > Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > > On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: > > > > > > > > > > > > Hi Andre, > > > > > > > > > > > > On 05.11.21 00:11, Andre Przywara wrote: > > > > > > > On Thu, 4 Nov 2021 11:37:57 +0100 > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > Hi Stefan, > > > > > > > > On 04.11.21 04:55, Samuel Holland wrote: > > > > > > > > > This series hooks up the watchdog uclass to automatically > > > > > > > > > register > > > > > > > > > watchdog devices for use with sysreset, doing a bit of minor > > > > > > > > > cleanup > > > > > > > > > along the way. > > > > > > > > > > > > > > > > > > The goal is for this to replace the sunxi board-level non-DM > > > > > > > > > reset_cpu() > > > > > > > > > function. I was surprised to find that the wdt_reboot driver > > > > > > > > > requires > > > > > > > > > its own undocumented device tree node, which references the > > > > > > > > > watchdog > > > > > > > > > device by phandle. This is problematic for us, because > > > > > > > > > sunxi-u-boot.dtsi > > > > > > > > > file covers 20 different SoCs with varying watchdog node > > > > > > > > > phandle names. > > > > > > > > > So it would have required adding a -u-boot.dtsi file for each > > > > > > > > > board. > > > > > > > > > > > > > > > > > > Hooking things up automatically makes sense to me; this is > > > > > > > > > what Linux > > > > > > > > > does. However, I put the code behind a new option to avoid > > > > > > > > > surprises for > > > > > > > > > other platforms. > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > - Move condition to wdt-uclass.c to fix build errors. > > > > > > > > > - Include watchdog name in error message. > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > - Extend the "if SYSRESET" block to the end of the file. > > > > > > > > > - Also make gpio_reboot_probe function static. > > > > > > > > > - Rebase on top of 492ee6b8d0e7 (now handle all > > > > > > > > > watchdogs). > > > > > > > > > - Added patches 5-6 as an example of how the new option > > > > > > > > > will be used. > > > > > > > > > > > > > > > > > > Samuel Holland (6): > > > > > > > > > sysreset: Add uclass Kconfig dependency to drivers > > > > > > > > > sysreset: Mark driver probe functions as static > > > > > > > > > sysreset: watchdog: Move watchdog reference to plat data > > > > > > > > > watchdog: Automatically register device with sysreset > > > > > > > > > sunxi: Avoid duplicate reset_cpu with SYSRESET enabled > > > > > > > > > sunxi: Use sysreset framework for poweroff/reset > > > > > > > > > > > > > > > > > > arch/arm/Kconfig | 3 +++ > > > > > > > > > arch/arm/mach-sunxi/board.c | 2 ++ > > > > > > > > > drivers/sysreset/Kconfig | 11 ++-- > > > > > > > > > drivers/sysreset/sysreset_gpio.c | 2 +- > > > > > > > > > drivers/sysreset/sysreset_resetctl.c | 2 +- > > > > > > > > > drivers/sysreset/sysreset_syscon.c | 2 +- > > > > > > > > > drivers/sysreset/sysreset_watchdog.c | 40 > > > > > > > > > ++-- > > > > > > > > > drivers/watchdog/wdt-uclass.c| 8 ++ > > > > > > > > > include/sysreset.h | 10 +++ > > > > > > > > > 9 files changed, 67 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > > > Applied to u-boot-marvell > > > > > > > > > > > > > > Mmmh, why u-boot-marvell, > > > > > > > > > > > > Because I'm handling watchdog related changed since a few years and > > > > > > we > > > > > > did not create a specific subsystem repo for this and I'm usually > > > > > > using my "marvell" one for this. > > > > And fwiw, there's a few other cases like this. If it's too confusing, > > maybe we should just roll out a few more repositories, I think it's > > easier to do that now than pre-gitlab? No, that's fine, I was just briefly confused about the Marvell part. > > > > > > > and why did this end up already in master? > > > > > > > Isn't that material for the next merge window? After all this > > > > > > > changes > > > > > > > quite a bit, for a lot of boards, and I did not have a closer > > > > > > > look at > > > > > > > the sunxi parts yet. > > > > > > > > > > > > I was hesitating also a bit. But since this patchset is on the list > > > > > > in > > > > > > v1 since over 2 months now (2021-08-21) I thought it was "ready" for > > > > > > inclusion now. We are at -rc1 and I think we still have enough time > > > > > > to > > > > > > fix any resulting
[PATCH] usb: Use the first available device for ehci_gadget
For whatever reason, usb_setup_ehci_gadget removes and probes USB device 0. However, not all systems have a device 0. Use the first device instead. The device probed should probably have something to do with the controller (as specified by e.g. ums or fastboot ). In fact, I find it odd that we probe the USB device in the first place, because this is just to set up the gadget itself. Presumably, the controller should be probed by usb_gadget_initialize somehow. Signed-off-by: Sean Anderson --- drivers/usb/host/usb-uclass.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c index fd39c3345c..27e2fc6fcd 100644 --- a/drivers/usb/host/usb-uclass.c +++ b/drivers/usb/host/usb-uclass.c @@ -396,7 +396,7 @@ int usb_setup_ehci_gadget(struct ehci_ctrl **ctlrp) int ret; /* Find the old device and remove it */ - ret = uclass_find_device_by_seq(UCLASS_USB, 0, ); + ret = uclass_find_first_device(UCLASS_USB, ); if (ret) return ret; ret = device_remove(dev, DM_REMOVE_NORMAL); @@ -419,7 +419,7 @@ int usb_remove_ehci_gadget(struct ehci_ctrl **ctlrp) int ret; /* Find the old device and remove it */ - ret = uclass_find_device_by_seq(UCLASS_USB, 0, ); + ret = uclass_find_first_device(UCLASS_USB, ); if (ret) return ret; ret = device_remove(dev, DM_REMOVE_NORMAL); -- 2.25.1
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Simon, Le ven. 5 nov. 2021 à 17:12, Simon Glass a écrit : > Hi François, > > On Fri, 5 Nov 2021 at 02:27, François Ozog > wrote: > > > > > > > > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 2 Nov 2021 at 10:03, François Ozog > wrote: > >> > > >> > Hi Simon, > >> > > >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog > wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > this seems a great endeavor. I'd like to better understand the > scope of it. > >> >> > > >> >> > Is it to be used as part of what could become a U-Boot entry ABI > scheme? By that I mean giving some fixed aspects > >> >> > to U-Boot entry while letting boards to have flexibility (say for > instance that the first 5 architecture ABI > >> >> > parameter registers are reserved for U-Boot), and the Passage is > about specifying either those reserved registers > >> >> > or one of them? > >> >> > >> >> The goal is to provide a standard entry scheme for all firmware > >> >> binaries. Whether it achieves that (or can with some mods) is up for > >> >> discussion. > >> >> > >> > If you say > >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware > information passing facility which would be part of all firmware ABIs (as > the projects decide to define their own ABI) it looks good. > >> > but If you say > >> > >> It is an ABI to be adopted by U-Boot but also other firmware. For > >> example, if TF-A calls U-Boot it should use standard passage. If > >> U-Boot calls TF-A or Optee it should use standard passage. > >> > >> > b) define a standard entry scheme (register map, processor state, MMU > state, SMMU state, GIC state...) that does not look realistic. > >> > >> No I don't mean that. This data structure could be used in any state, > >> so long as the two registers are set correctly. > >> > >> > I think you mean a) but just want to be sure. > >> > >> Yes I think so. > >> > >> >> > >> >> Re the registers, do you think we need 5? > >> >> > >> > >> I don't :-) > >> > >> >> > > >> >> > Thinking entry ABI, here is what I observed on Arm: > >> >> > > >> >> > Linux has two entry ABIs: > >> >> > - plain: x0 = dtb; > >> >> > command line = dtb:/chosen/bootargs; initrd = > dtb:/chosen/linux,initrd-* > >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; > >> >> >dtb = EFI_UUID config table; initrd = > efi: image_protocol::load_options > >> >> > > >> >> > U-Boot (proper) has plenty of schemes: > >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is > bad in itself), or other registers > >> >> > - additional information passing: board specific register scheme, > SMC calls > >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be > launched by Videocore firmware > >> >> > > >> >> > Based on all the above, I would tend to think that RPI scheme is a > good idea but also > >> >> > shall not prevent additional schemes for the boards. > >> >> > >> >> I was not actually considering Linux since I believe/assume its entry > >> >> scheme is fixed and not up for discussion. > >> >> > >> >> I also did not think about the EFI case. As I understand it we cannot > >> >> touch it as it is used by UEFI today. Maybe it is even in the > >> >> standard? > >> > > >> > It is in the spec and we are making it evolve, or its understanding > evolve (jurisprudence) for instance on initrd standard handling. > >> > >> Well perhaps we could merge it with standard passage. But EFI is not > >> going to want to use a bloblist, it will want to use a HOB. > >> > >> >> > >> >> > >> >> Really I am hoping we can start afresh...? > >> >> > >> >> > > >> >> > What about a U-Boot Arm entry ABI like: > >> >> > - plain: x0=dtb, x1=, x2-x5 = , other > registers are per platform, SMC calls allowed too > >> >> > >> >> Hmm we don't actually need the dtb as it is available in the > bloblist. > >> > > >> > If you don't have x0=dtb, then you will not be able to use U-Boot on > RPI4. > >> > Unless you want to redo everything the RPI firmware is doing. > >> > >> That's right, RPI cannot support standard passage. It is not > >> open-source firmware so it isn't really relevant to this discussion. > >> It will just do what it does and have limited functionality, with > >> work-arounds to deal with the pain, as one might expect. > >> > > So you are seeing two "all-or-nothing" options: > > : U-Boot entry is board specific as it is today > > : A new form where the only parameter is a head of > bloblist, one of those blobs contain a DT > > You propose to mandate a DT for all boards make sense in that > environment. > > For RPI4, you just ignore everything the prior boot loader does because > it is not compliant. > > It's not that. It's just that it is closed-source, so not relevant to > the discussion here. They could open-source it and then we could > consider it, but it has been
Re: [PATCH 2/6 v4] tpm2: Add a TPMv2 MMIO TIS driver
Hi Ilias,
On Fri, 5 Nov 2021 at 02:23, Ilias Apalodimas
wrote:
>
> On Fri, Nov 05, 2021 at 10:17:21AM +0200, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > [...]
> >
> > > > + u8 *result)
> > > > +{
> > > > + struct tpm_tis_chip_data *drv_data = (void
> > > > *)dev_get_driver_data(udev);
> > > > +
> > > > + while (len--)
> > > > + *result++ = ioread8(drv_data->iobase + addr);
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int mmio_write_bytes(struct udevice *udev, u32 addr, u16 len,
> > > > + const u8 *value)
> > > > +{
> > > > + struct tpm_tis_chip_data *drv_data = (void
> > > > *)dev_get_driver_data(udev);
> > > > +
> > > > + while (len--)
> > > > + iowrite8(*value++, drv_data->iobase + addr);
> > >
> > > So should this use regmap?
> > >
> >
> > Isn't the point of regmap abstracting the bus access itself? Something
> > along the lines of
It is for MMIO at present, but I suppose it could handle the bus. It
would need to know about register numbers though, and we've never
really figured out if it is a win or not.
> >
> > ** ***
> > * SPI ** --> ** --> * SPI DM ** --> Device
> > ** ***
> > * REGMAP *
> > **
> > * MMIO * --> ** --> **
> > ** * MMIO access* -->
> > Device
> >
> > **
> >
>
> Hopefully I'll get the ASCII right this time...
>
> ** ***
> * SPI ** --> ** --> * SPI DM ** --> Device
> ** ***
> * REGMAP *
> **
> * MMIO * --> ** --> **
> ** * MMIO access* --> Device
>**
> > Right now we have discrete drivers for the SPI and MMIO TPMs.
> > However using it makes sense if we want to merge parts of the SPI, MMIO and
> > I2C
> > drivers in the future. That though is not what this patchset deals with.
> > Let's first clean up the crud of the TIS APIs duplication we've been
> > carrying over various TPM drivers and worry about consolidating the bus
> > accesses later.
That's OK with me.
Regards,
Simon
Re: [PATCH v2 08/12] sysinfo: Add support for iterating string list
Hi Marek, On Fri, 5 Nov 2021 at 05:24, Marek Behún wrote: > > On Thu, 4 Nov 2021 20:02:29 -0600 > Simon Glass wrote: > > > Better to make iter a struct sysinfo_str_list_iter, I think and > > require the caller to declare it: > > > > sysinfo_str_list_iter iter; > > char str[80]' > > > > p = sysinfo_str_list_first(dev, i, , sizeof(str), ); > > ... > > > > Do you need the iter? > > > > If you want to support arbitratry length, I suppose that is OK?? But I > > don't like allocating memory unless it is needed. > > Well if I am iterating through default environment variables > overwrites, they can be basically up to ENV_SIZE long. There may be > some long commands stored there. OK. > > Another solution would be to redesign sysinfo_get_str() and introduce > sysinfo_get_str_list() so that they won't fill a buffer given by user, > but instead have their own buffer in implementation and return const > char * pointer. Yes that was a design idea at the start...but I think at present I like the current API. I just didn't understand your intent properly. My new thoughts: - pass in the iter so malloc() is not needed there (change str to a char *) - return an int from your iterator functions, so you can tell when you run out of memory and need to die - comment struct sysinfo_str_list_iter - use log_debug() instead of printf(), on error Also I wonder about this: - get the caller to provide the str buffer, and maxsize, so malloc() is not needed I can see the advantage of allocating though. I wonder if you might keep track of the current buffer length and do a realloc() if it is too small, each time? Scanning through to find the max length might be slower? Some drivers may read from an I2C device, for example. Regards, Simon
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi François, On Fri, 5 Nov 2021 at 02:27, François Ozog wrote: > > > > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: >> >> Hi François, >> >> On Tue, 2 Nov 2021 at 10:03, François Ozog wrote: >> > >> > Hi Simon, >> > >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: >> >> >> >> Hi François, >> >> >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog >> >> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > this seems a great endeavor. I'd like to better understand the scope of >> >> > it. >> >> > >> >> > Is it to be used as part of what could become a U-Boot entry ABI >> >> > scheme? By that I mean giving some fixed aspects >> >> > to U-Boot entry while letting boards to have flexibility (say for >> >> > instance that the first 5 architecture ABI >> >> > parameter registers are reserved for U-Boot), and the Passage is about >> >> > specifying either those reserved registers >> >> > or one of them? >> >> >> >> The goal is to provide a standard entry scheme for all firmware >> >> binaries. Whether it achieves that (or can with some mods) is up for >> >> discussion. >> >> >> > If you say >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware >> > information passing facility which would be part of all firmware ABIs (as >> > the projects decide to define their own ABI) it looks good. >> > but If you say >> >> It is an ABI to be adopted by U-Boot but also other firmware. For >> example, if TF-A calls U-Boot it should use standard passage. If >> U-Boot calls TF-A or Optee it should use standard passage. >> >> > b) define a standard entry scheme (register map, processor state, MMU >> > state, SMMU state, GIC state...) that does not look realistic. >> >> No I don't mean that. This data structure could be used in any state, >> so long as the two registers are set correctly. >> >> > I think you mean a) but just want to be sure. >> >> Yes I think so. >> >> >> >> >> Re the registers, do you think we need 5? >> >> >> >> I don't :-) >> >> >> > >> >> > Thinking entry ABI, here is what I observed on Arm: >> >> > >> >> > Linux has two entry ABIs: >> >> > - plain: x0 = dtb; >> >> > command line = dtb:/chosen/bootargs; initrd = >> >> > dtb:/chosen/linux,initrd-* >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> >> >dtb = EFI_UUID config table; initrd = efi:> >> > vendor media UUID); command line = efi: image_protocol::load_options >> >> > >> >> > U-Boot (proper) has plenty of schemes: >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad >> >> > in itself), or other registers >> >> > - additional information passing: board specific register scheme, SMC >> >> > calls >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be >> >> > launched by Videocore firmware >> >> > >> >> > Based on all the above, I would tend to think that RPI scheme is a good >> >> > idea but also >> >> > shall not prevent additional schemes for the boards. >> >> >> >> I was not actually considering Linux since I believe/assume its entry >> >> scheme is fixed and not up for discussion. >> >> >> >> I also did not think about the EFI case. As I understand it we cannot >> >> touch it as it is used by UEFI today. Maybe it is even in the >> >> standard? >> > >> > It is in the spec and we are making it evolve, or its understanding evolve >> > (jurisprudence) for instance on initrd standard handling. >> >> Well perhaps we could merge it with standard passage. But EFI is not >> going to want to use a bloblist, it will want to use a HOB. >> >> >> >> >> >> >> Really I am hoping we can start afresh...? >> >> >> >> > >> >> > What about a U-Boot Arm entry ABI like: >> >> > - plain: x0=dtb, x1=, x2-x5 = , other >> >> > registers are per platform, SMC calls allowed too >> >> >> >> Hmm we don't actually need the dtb as it is available in the bloblist. >> > >> > If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. >> > Unless you want to redo everything the RPI firmware is doing. >> >> That's right, RPI cannot support standard passage. It is not >> open-source firmware so it isn't really relevant to this discussion. >> It will just do what it does and have limited functionality, with >> work-arounds to deal with the pain, as one might expect. >> > So you are seeing two "all-or-nothing" options: > : U-Boot entry is board specific as it is today > : A new form where the only parameter is a head of bloblist, one > of those blobs contain a DT > You propose to mandate a DT for all boards make sense in that environment. > For RPI4, you just ignore everything the prior boot loader does because it is > not compliant. It's not that. It's just that it is closed-source, so not relevant to the discussion here. They could open-source it and then we could consider it, but it has been closed-source for years now, so why would we think that would happen? > > This reinforces my opposition to the mandatory DT proposal. > > a third option is I think
Re: [PATCH v5 05/11] test/py: efi_capsule: add image authentication test
Hi Takahiro,
On Thu, 4 Nov 2021 at 21:24, AKASHI Takahiro wrote:
>
> On Thu, Nov 04, 2021 at 08:02:37PM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Thu, 4 Nov 2021 at 19:21, AKASHI Takahiro
> > wrote:
> > >
> > > On Wed, Nov 03, 2021 at 08:49:04PM -0600, Simon Glass wrote:
> > > > Hi Takahiro,
> > > >
> > > > On Wed, 3 Nov 2021 at 20:04, AKASHI Takahiro
> > > > wrote:
> > > > >
> > > > > On Tue, Nov 02, 2021 at 08:58:15AM -0600, Simon Glass wrote:
> > > > > > Hi Takahiro,
> > > > > >
> > > > > > On Thu, 28 Oct 2021 at 23:25, AKASHI Takahiro
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Oct 28, 2021 at 09:17:49PM -0600, Simon Glass wrote:
> > > > > > > > Hi Takahiro,
> > > > > > > >
> > > > > > > > On Thu, 28 Oct 2021 at 00:25, AKASHI Takahiro
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Add a couple of test cases against capsule image
> > > > > > > > > authentication
> > > > > > > > > for capsule-on-disk, where only a signed capsule file with
> > > > > > > > > the verified
> > > > > > > > > signature will be applied to the system.
> > > > > > > > >
> > > > > > > > > Due to the difficulty of embedding a public key (esl file) in
> > > > > > > > > U-Boot
> > > > > > > > > binary during pytest setup time, all the keys/certificates
> > > > > > > > > are pre-created.
> > > > > > > > >
> > > > > > > > > Signed-off-by: AKASHI Takahiro
> > > > > > > > > ---
> > > > > > > > > .../py/tests/test_efi_capsule/capsule_defs.py | 5 +
> > > > > > > > > test/py/tests/test_efi_capsule/conftest.py| 35 ++-
> > > > > > > > > test/py/tests/test_efi_capsule/signature.dts | 10 +
> > > > > > > > > .../test_capsule_firmware_signed.py | 233
> > > > > > > > > ++
> > > > > > > > > 4 files changed, 280 insertions(+), 3 deletions(-)
> > > > > > > > > create mode 100644
> > > > > > > > > test/py/tests/test_efi_capsule/signature.dts
> > > > > > > > > create mode 100644
> > > > > > > > > test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py
> > > > > > > > >
> > > > > > > > > diff --git a/test/py/tests/test_efi_capsule/capsule_defs.py
> > > > > > > > > b/test/py/tests/test_efi_capsule/capsule_defs.py
> > > > > > > > > index 4fd6353c2040..aa9bf5eee3aa 100644
> > > > > > > > > --- a/test/py/tests/test_efi_capsule/capsule_defs.py
> > > > > > > > > +++ b/test/py/tests/test_efi_capsule/capsule_defs.py
> > > > > > > > > @@ -3,3 +3,8 @@
> > > > > > > > > # Directories
> > > > > > > > > CAPSULE_DATA_DIR = '/EFI/CapsuleTestData'
> > > > > > > > > CAPSULE_INSTALL_DIR = '/EFI/UpdateCapsule'
> > > > > > > > > +
> > > > > > > > > +# v1.5.1 or earlier of efitools has a bug in sha256
> > > > > > > > > calculation, and
> > > > > > > > > +# you need build a newer version on your own.
> > > > > > > > > +# The path must terminate with '/'.
> > > > > > > > > +EFITOOLS_PATH = ''
> > > > > > > > > diff --git a/test/py/tests/test_efi_capsule/conftest.py
> > > > > > > > > b/test/py/tests/test_efi_capsule/conftest.py
> > > > > > > > > index 6ad5608cd71c..b0e84dec4931 100644
> > > > > > > > > --- a/test/py/tests/test_efi_capsule/conftest.py
> > > > > > > > > +++ b/test/py/tests/test_efi_capsule/conftest.py
> > > > > > > > > @@ -10,13 +10,13 @@ import pytest
> > > > > > > > > from capsule_defs import *
> > > > > > > > >
> > > > > > > > > #
> > > > > > > > > -# Fixture for UEFI secure boot test
> > > > > > > > > +# Fixture for UEFI capsule test
> > > > > > > > > #
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > @pytest.fixture(scope='session')
> > > > > > > > > def efi_capsule_data(request, u_boot_config):
> > > > > > > > > -"""Set up a file system to be used in UEFI capsule test.
> > > > > > > > > +"""Set up a file system to be used in UEFI capsule and
> > > > > > > > > + authentication test.
> > > > > > > > >
> > > > > > > > > Args:
> > > > > > > > > request: Pytest request object.
> > > > > > > > > @@ -40,6 +40,26 @@ def efi_capsule_data(request,
> > > > > > > > > u_boot_config):
> > > > > > > > > check_call('mkdir -p %s' % data_dir, shell=True)
> > > > > > > > > check_call('mkdir -p %s' % install_dir, shell=True)
> > > > > > > > >
> > > > > > > > > +capsule_auth_enabled = u_boot_config.buildconfig.get(
> > > > > > > > > +'config_efi_capsule_authenticate')
> > > > > > > > > +if capsule_auth_enabled:
> > > > > > > > > +# Create private key (SIGNER.key) and
> > > > > > > > > certificate (SIGNER.crt)
> > > > > > > > > +check_call('cd %s; openssl req -x509 -sha256
> > > > > > > > > -newkey rsa:2048 -subj /CN=TEST_SIGNER/ -keyout SIGNER.key
> > > > > > > > > -out SIGNER.crt -nodes -days 365'
> > > > > > > > > + % data_dir, shell=True)
> > > > > > > >
> > > > > > > > run_and_log()?
> > > > > > >
> > > > > > > I have always used this style of coding in this file as well as
> > > > > > > other my pytests in test/py/tests
Re: [RFC 2/2] binman: catch RunException for mkimage runtime failure
Hi Heiko,
On Fri, 5 Nov 2021 at 01:50, Heiko Thiery wrote:
>
> Hi Simon,
>
> Am Fr., 5. Nov. 2021 um 03:02 Uhr schrieb Simon Glass :
> >
> > Hi Heiko,
> >
> > On Thu, 4 Nov 2021 at 12:53, Heiko Thiery wrote:
> > >
> > > In case mkimage exits with a return code other than zero do not stop.
> > > Print an error message and go on.
> > >
> > > Signed-off-by: Heiko Thiery
> > > ---
> > > tools/binman/etype/mkimage.py | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > Somehow we need to record that it failed, at least.
>
> By record do you mean that it should not only be output as an error
> message (as already done), but should be remembered like e.g. the
> missing external blobs?
Yes that's right. If you say
self.missing = True
in there it should do the right thing.
Also, I wonder if we should have a separate return value from mkimage
so we know for sure that the cause was missing input files? We can
worry about that later, I suppose.
Regards,
Simon
>
> >
> > >
> > > diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
> > > index e49977522e..24fbe79172 100644
> > > --- a/tools/binman/etype/mkimage.py
> > > +++ b/tools/binman/etype/mkimage.py
> > > @@ -10,6 +10,7 @@ from collections import OrderedDict
> > > from binman.entry import Entry
> > > from dtoc import fdt_util
> > > from patman import tools
> > > +from patman import tout
> > >
> > > class Entry_mkimage(Entry):
> > > """Binary produced by mkimage
> > > @@ -51,7 +52,12 @@ class Entry_mkimage(Entry):
> > > input_fname = tools.GetOutputFilename('mkimage.%s' % uniq)
> > > tools.WriteFile(input_fname, data)
> > > output_fname = tools.GetOutputFilename('mkimage-out.%s' % uniq)
> > > -tools.Run('mkimage', '-d', input_fname, *self._args,
> > > output_fname)
> > > +
> > > +try:
> > > +tools.Run('mkimage', '-d', input_fname, *self._args,
> > > output_fname)
> > > +except Exception as e:
> > > +tout.Error("mkimage failed: %s" % e)
> > > +
> > > self.SetContents(tools.ReadFile(output_fname))
> > > return True
> > >
> > > --
> > > 2.30.2
> > >
> >
> > Regards,
> > SImon
>
> --
> Heiko
Re: [PATCH v5 04/11] doc: update UEFI document for usage of mkeficapsule
Hi Takahiro, On Thu, 4 Nov 2021 at 21:15, AKASHI Takahiro wrote: > > On Thu, Nov 04, 2021 at 09:11:51AM -0600, Simon Glass wrote: > > Hi Takahiro, > > > > On Wed, 3 Nov 2021 at 19:49, AKASHI Takahiro > > wrote: > > > > > > On Tue, Nov 02, 2021 at 08:57:48AM -0600, Simon Glass wrote: > > > > Hi Takahiro, > > > > > > > > On Thu, 28 Oct 2021 at 23:20, AKASHI Takahiro > > > > wrote: > > > > > > > > > > On Thu, Oct 28, 2021 at 09:17:48PM -0600, Simon Glass wrote: > > > > > > Hi Takahiro, > > > > > > > > > > > > On Thu, 28 Oct 2021 at 00:25, AKASHI Takahiro > > > > > > wrote: > > > > > > > > > > > > > > Now we can use mkeficapsule command instead of EDK-II's script > > > > > > > to create a signed capsule file. So update the instruction for > > > > > > > capsule authentication. > > > > > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > > > --- > > > > > > > doc/develop/uefi/uefi.rst | 143 > > > > > > > ++ > > > > > > > 1 file changed, 67 insertions(+), 76 deletions(-) > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > > thoughts below > > > > > > > > > > > > > > > > > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > > > > > > index f17138f5c765..864d61734bee 100644 > > > > > > > --- a/doc/develop/uefi/uefi.rst > > > > > > > +++ b/doc/develop/uefi/uefi.rst > > > > > > > @@ -284,37 +284,52 @@ Support has been added for the UEFI capsule > > > > > > > update feature which > > > > > > > enables updating the U-Boot image using the UEFI firmware > > > > > > > management > > > > > > > protocol (FMP). The capsules are not passed to the firmware > > > > > > > through > > > > > > > the UpdateCapsule runtime service. Instead, capsule-on-disk > > > > > > > -functionality is used for fetching the capsule from the EFI > > > > > > > System > > > > > > > -Partition (ESP) by placing the capsule file under the > > > > > > > -\EFI\UpdateCapsule directory. > > > > > > > - > > > > > > > -The directory \EFI\UpdateCapsule is checked for capsules only > > > > > > > within the > > > > > > > -EFI system partition on the device specified in the active boot > > > > > > > option > > > > > > > -determined by reference to BootNext variable or BootOrder > > > > > > > variable processing. > > > > > > > -The active Boot Variable is the variable with highest priority > > > > > > > BootNext or > > > > > > > -within BootOrder that refers to a device found to be present. > > > > > > > Boot variables > > > > > > > -in BootOrder but referring to devices not present are ignored > > > > > > > when determining > > > > > > > -active boot variable. > > > > > > > -Before starting a capsule update make sure your capsules are > > > > > > > installed in the > > > > > > > -correct ESP partition or set BootNext. > > > > > > > +functionality is used for fetching capsules from the EFI System > > > > > > > +Partition (ESP) by placing capsule files under the directory:: > > > > > > > + > > > > > > > +\EFI\UpdateCapsule > > > > > > > > > > > > Can we use forward slashes please? > > > > > > > > > > > > What is a backslash, even? DOS? Windows? > > > > > > > > > > UEFI specification. > > > > > In this document, all the file paths are presented with backslashes. > > > > > (See section 8.5.5 in version 2.9) > > > > > > > > > > Anyhow U-Boot UEFI internally converts the path with slashes. > > > > > > > > So do we need to use backslashes in U-Boot and in the docs? Can we use > > > > a forward slash instead? I had hoped those days were behind us. The > > > > backslash is used for C escapes, after all. > > > > > > I'd defer to the maintainer, Heinrich here. > > > > > > > > > > > > > > > + > > > > > > > +The directory is checked for capsules only within the > > > > > > > +EFI system partition on the device specified in the active boot > > > > > > > option, > > > > > > > +which is determined by Boot variable in BootNext, or if not, > > > > > > > the highest > > > > > > > +priority one within BootOrder. Any Boot variables referring > > > > > > > to devices > > > > > > > +not present are ignored when determining the active boot option. > > > > > > > + > > > > > > > +Please note that capsules will be applied in the alphabetic > > > > > > > order of > > > > > > > +capsule file names. > > > > > > > + > > > > > > > +Creating a capsule file > > > > > > > +*** > > > > > > > + > > > > > > > +A capsule file can be created by using tools/mkeficapsule. > > > > > > > +To build this tool, enable:: > > > > > > > + > > > > > > > +CONFIG_TOOLS_MKEFICAPSULE=y > > > > > > > +CONFIG_TOOLS_LIBCRYPTO=y > > > > > > > + > > > > > > > +Run the following command:: > > > > > > > + > > > > > > > +$ mkeficapsule \ > > > > > > > + --index 1 --instance 0 \ > > > > > > > + [--fit | --raw ] \ > > > > > > > + > > > > > > > > > > > > > > Performing the update > > > > > > > * > > > > > > > > > > > > > > -Since
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
Hi Takahiro, On Thu, 4 Nov 2021 at 20:49, AKASHI Takahiro wrote: > > On Thu, Nov 04, 2021 at 08:02:05PM -0600, Simon Glass wrote: > > Hi, > > > > On Tue, 2 Nov 2021 at 01:43, Heinrich Schuchardt wrote: > > > > > > > > > > > > On 11/1/21 03:14, Simon Glass wrote: > > > > Hi Takahiro, > > > > > > > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro > > > > wrote: > > > >> > > > >> On Sun, Oct 31, 2021 at 07:15:17PM -0600, Simon Glass wrote: > > > >>> Hi Takahiro, > > > >>> > > > >>> On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro > > > >>> wrote: > > > > > > On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass > > > > : > > > >> Hi, > > > >> > > > >> On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt > > > >> wrote: > > > >>> > > > >>> > > > >>> > > > >>> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro > > > >>> : > > > On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt > > > wrote: > > > > > > > > > > > >> I agree with Heinrich that we are better to leave BLK as it > > > >> is, both > > > >> in name and meaning. I think maybe I am missing the gist of > > > >> your > > > >> argument. > > > >> > > > >> If we use UCLASS_PART, for example, can we have that refer to > > > >> both s/w > > > >> and h/w partitions, as Herinch seems to allude to below? What > > > >> would > > > >> the picture look like the, and would it get us closer to > > > >> agreement? > > > > > > > > In the driver model: > > > > > > > > A UCLASS is a class of drivers that share the same interface. > > > > A UDEVICE is a logical device that belongs to exactly one > > > > UCLASS and is > > > > accessed through this UCLASS's interface. > > > > > > Please be careful about "accessed through" which is a quite > > > confusing > > > expression. I don't always agree with this view. > > > > > > > A hardware partition is an object that exposes only a single > > > > interface > > > > for block IO. > > > > > > > > A software partition is an object that may expose two > > > > interfaces: one > > > > for block IO, the other for file IO. > > > > > > Are you talking about UEFI world or U-Boot? > > > Definitely, a hw partitions can provide a file system > > > if you want. > > > It's a matter of usage. > > > > > > I remember that we had some discussion about whether block > > > devices > > > on UEFI system should always have a (sw) partition table or not. > > > But it is a different topic. > > > > > > > The UEFI model does not have a problem with this because on a > > > > handle you > > > > can install as many different protocols as you wish. But > > > > U-Boot's driver > > > > model only allows a single interface per device. Up to now > > > > U-Boot has > > > > overcome this limitation by creating child devices for the > > > > extra interfaces. > > > > > > > We have the following logical levels: > > > > > > > > Controller | Block device | Software Partition| File system > > > > +--+---+ > > > > NVMe Drive | Namespace| Partition 1..n| FAT, EXT4 > > > > ATA Controller | ATA-Drive| | > > > > SCSI Controller | LUN | | > > > > MMC Controller | HW-Partition | | > > > > MMC Controller | SD-Card | | > > > > USB-Node| USB-Drive| | > > > > > > > > In the device tree this could be modeled as: > > > > > > > > |-- Controller (UCLASS_CTRL) > > > > | |-- Block device / HW Partition (UCLASS_BLK)(A) > > > > | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) > > > > | | |-- Software Partition (UCLASS_BLK) > > > > | | |-- File system (UCLASS_FS) > > > > | | > > > > | |-- Block device (UCLASS_BLK) > > > > | |-- File system (UCLASS_FS) > > > > > > I don't know why we expect PARTITION_TABLE and FS to appear in > > > DM tree. > > > What is the benefit? > > > (A) and (B) always have 1:1 relationship. > > > >>> > > > >>> No. You can have a bare device without a partition table. > > > >> > > > >> I can have a DOS partition that covers the whole device, without a > > > >> partition table. This is supported in
Re: [PATCH v2 06/12] sysinfo: Add get_str_list() method
Hi Marek, On Fri, 5 Nov 2021 at 05:20, Marek Behún wrote: > > On Thu, 4 Nov 2021 20:02:27 -0600 > Simon Glass wrote: > > > On Wed, 3 Nov 2021 at 17:23, Marek Behún wrote: > > > > > > From: Marek Behún > > > > > > Add get_str_list() method to sysinfo operations. > > > > > > The get_str_list() method is similar to get_str(), but receives one > > > additional argument, @idx, and fills in the @idx-th string from a given > > > list. > > > > > > Add sandbox implementation together with a unittest. > > > > > > Signed-off-by: Marek Behún > > > --- > > > drivers/sysinfo/sandbox.c| 15 +++ > > > drivers/sysinfo/sysinfo-uclass.c | 15 +++ > > > include/sysinfo.h| 44 > > > test/dm/sysinfo.c| 13 ++ > > > 4 files changed, 87 insertions(+) > > > > > > > Reviewed-by: Simon Glass > > > > Except I think it should return -NOSPC if the buffer is too small. > > No because then you don't know how large buffer you actually need and > have to guess (or grow by a factor of two until it fits). > > This way you can call with size=0, get the length, allocate buffer and > call again. OK, I completely missed that. Can you mention this approach in the comments? "Actual length of the string" - does that mean the length that would have been returned if there were enough space? If so, please make that clear. Regards, Simon > > Marek
Re: [PATCH 1/6 v4] tpm2: Introduce TIS tpm core
Hi Ilias,
On Fri, 5 Nov 2021 at 01:02, Ilias Apalodimas
wrote:
>
> Hi Simon,
>
> [...]
> > >
> > > +int tpm_tis_open(struct udevice *udev);
> >
> > Please add comments
>
> There are comments for all of those in drivers/tpm/tpm2_tis_core.c,
> isn't that enough?
So just move them to the header file, then? If this is an API it needs
to be documented and at some point we'll want sphinx to pick it up for
htmldocs.
Regards,
Simon
>
> Thanks
> /Ilias
> >
> > > +int tpm_tis_close(struct udevice *udev);
> > > +int tpm_tis_cleanup(struct udevice *udev);
> > > +int tpm_tis_send(struct udevice *udev, const u8 *buf, size_t len);
> > > +int tpm_tis_recv(struct udevice *udev, u8 *buf, size_t count);
> > > +int tpm_tis_get_desc(struct udevice *udev, char *buf, int size);
> > > +int tpm_tis_init(struct udevice *udev);
> > > +void tpm_tis_ops_register(struct udevice *udev, struct tpm_tis_phy_ops
> > > *ops);
> > > #endif
> > > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > > index 13b3db67c60f..e6b68769f3ff 100644
> > > --- a/include/tpm-v2.h
> > > +++ b/include/tpm-v2.h
> > > @@ -396,6 +396,7 @@ enum {
> > > TPM_STS_DATA_EXPECT = 1 << 3,
> > > TPM_STS_SELF_TEST_DONE = 1 << 2,
> > > TPM_STS_RESPONSE_RETRY = 1 << 1,
> > > + TPM_STS_READ_ZERO = 0x23
> > > };
> > >
> > > enum {
> > > --
> > > 2.33.1
> > >
> >
> > Regards,
> > Simon
Re: [PATCH v2 04/12] sysinfo: Make sysinfo_get_str() behave like snprintf()
Hi Marek, On Fri, 5 Nov 2021 at 05:19, Marek Behún wrote: > > On Thu, 4 Nov 2021 20:02:25 -0600 > Simon Glass wrote: > > > Hi Marek, > > > > On Wed, 3 Nov 2021 at 17:23, Marek Behún wrote: > > > > > > From: Marek Behún > > > > > > Currently sysinfo_get_str() returns 0 if a string is filled in the > > > given buffer, and otherwise gives no simple mechanism to determine > > > actual string length. > > > > > > One implementation returns -ENOSPC if buffer is not large enough. > > > > > > Change the behaviour of the function to that of snprintf(): i.e. the > > > buffer is always filled in as much as possible if the string exists, and > > > the function returns the actual length of the string (excluding the > > > terminating NULL-byte). > > > > > > Signed-off-by: Marek Behún > > > --- > > > board/google/chromebook_coral/coral.c | 13 - > > > common/board_info.c | 2 +- > > > drivers/sysinfo/gpio.c| 2 +- > > > drivers/sysinfo/rcar3.c | 2 +- > > > drivers/sysinfo/sandbox.c | 5 +++-- > > > include/sysinfo.h | 16 > > > lib/smbios.c | 2 +- > > > test/dm/sysinfo-gpio.c| 12 ++-- > > > test/dm/sysinfo.c | 12 ++-- > > > 9 files changed, 35 insertions(+), 31 deletions(-) > > > > So how do we know if the size is too small? The string is silently > > truncated? > > The same way as in snprintf. > If the return value is >= size, then size is too small. > (The return value is the length of the whole string (excluding \0 at > end), not just the part that was copied to buffer.) OK, as on the other patch for where I missed this. It is in the commit message which I did not read carefully enough, but we need it in the header file / sphinx docs too. Regards, Simon > > Marek
Re: Injecting public keys into FTDs for FIT verification
Hi, On Fri, 5 Nov 2021 at 07:04, Jan Kiszka wrote: > > On 05.11.21 13:42, Jan Kiszka wrote: > > On 05.11.21 11:28, Rasmus Villemoes wrote: > >> On 05/11/2021 11.16, Jan Kiszka wrote: > >>> Hi all, > >>> > >>> in order to use CONFIG_FIT_SIGNATURE and also > >>> CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the > >>> control FDT. So far, I only found mkimage being able to do that during > >>> FIT image signing. That is fairly unhandy and often incompatible with > >>> how firmware is built & signed vs. how the lifecycle of the artifacts to > >>> be loaded and verified look like. Is there really no other way than > >>> mkimage -K? > >>> > >>> I'm currently considering to derive a tool that, given a public key > >>> (which is easy to hand around, compared to the private key needed for > >>> signing), injects them into a FDT. Then I would hook that up as generic > >>> feature for U-Boot builds, enriching all control FTDs already during the > >>> first build with this when requested. > >>> > >>> Am I missing an even simpler approach? > >> > >> You're not missing an existing upstream simpler approach, but it's > >> certainly an itch that others have had [1] [2]. My latest attempt > >> > >> https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villem...@prevas.dk/ > >> > > Looking at this path: I would also need it for SPL, so that SPL can > validate the container for the main U-Boot. Seems that is missing here, > isn't it? > > Jan > > >> does now have an R-b by Simon, so now I'm just waiting for that to > >> actually make it into master. I have the script(s) that will convert a > >> public key to a .dtsi fragment, and I'm happy to share that. > >> > > > > Cool, that would be very welcome! What I'd really like is a separate tool. It was sent as attachments but we are waiting for the author to send them as patches on the thread "Introduce CONFIG_DEVICE_TREE_INCLUDES". BTW, Rasmus, some documentation on this patch would be helpful. Regards, Simon > > > > Jan > > > >> Rasmus > >> > >> [1] > >> https://lore.kernel.org/u-boot/CAO5Uq5TyTMacERo01weTEda-5X4Fx-VUoYFHa=mbyhw-rvm...@mail.gmail.com/ > >> [2] > >> https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f5...@kaspersky.com/ > >> > > > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux
Re: [PATCH v3 0/6] Improved sysreset/watchdog uclass integration
Hi, On Fri, 5 Nov 2021 at 08:21, Tom Rini wrote: > > On Fri, Nov 05, 2021 at 12:14:47PM +0100, Stefan Roese wrote: > > Hi Andre, > > > > Added Tom to Cc. > > > > On 05.11.21 11:04, Andre Przywara wrote: > > > On Thu, 4 Nov 2021 20:02:41 -0600 > > > Simon Glass wrote: > > > > > > Hi, > > > > > > > On Thu, 4 Nov 2021 at 19:22, Stefan Roese wrote: > > > > > > > > > > Hi Andre, > > > > > > > > > > On 05.11.21 00:11, Andre Przywara wrote: > > > > > > On Thu, 4 Nov 2021 11:37:57 +0100 > > > > > > Stefan Roese wrote: > > > > > > > > > > > > Hi Stefan, > > > > > > > On 04.11.21 04:55, Samuel Holland wrote: > > > > > > > > This series hooks up the watchdog uclass to automatically > > > > > > > > register > > > > > > > > watchdog devices for use with sysreset, doing a bit of minor > > > > > > > > cleanup > > > > > > > > along the way. > > > > > > > > > > > > > > > > The goal is for this to replace the sunxi board-level non-DM > > > > > > > > reset_cpu() > > > > > > > > function. I was surprised to find that the wdt_reboot driver > > > > > > > > requires > > > > > > > > its own undocumented device tree node, which references the > > > > > > > > watchdog > > > > > > > > device by phandle. This is problematic for us, because > > > > > > > > sunxi-u-boot.dtsi > > > > > > > > file covers 20 different SoCs with varying watchdog node > > > > > > > > phandle names. > > > > > > > > So it would have required adding a -u-boot.dtsi file for each > > > > > > > > board. > > > > > > > > > > > > > > > > Hooking things up automatically makes sense to me; this is what > > > > > > > > Linux > > > > > > > > does. However, I put the code behind a new option to avoid > > > > > > > > surprises for > > > > > > > > other platforms. > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > - Move condition to wdt-uclass.c to fix build errors. > > > > > > > > - Include watchdog name in error message. > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > - Extend the "if SYSRESET" block to the end of the file. > > > > > > > > - Also make gpio_reboot_probe function static. > > > > > > > > - Rebase on top of 492ee6b8d0e7 (now handle all watchdogs). > > > > > > > > - Added patches 5-6 as an example of how the new option > > > > > > > > will be used. > > > > > > > > > > > > > > > > Samuel Holland (6): > > > > > > > > sysreset: Add uclass Kconfig dependency to drivers > > > > > > > > sysreset: Mark driver probe functions as static > > > > > > > > sysreset: watchdog: Move watchdog reference to plat data > > > > > > > > watchdog: Automatically register device with sysreset > > > > > > > > sunxi: Avoid duplicate reset_cpu with SYSRESET enabled > > > > > > > > sunxi: Use sysreset framework for poweroff/reset > > > > > > > > > > > > > > > > arch/arm/Kconfig | 3 +++ > > > > > > > > arch/arm/mach-sunxi/board.c | 2 ++ > > > > > > > > drivers/sysreset/Kconfig | 11 ++-- > > > > > > > > drivers/sysreset/sysreset_gpio.c | 2 +- > > > > > > > > drivers/sysreset/sysreset_resetctl.c | 2 +- > > > > > > > > drivers/sysreset/sysreset_syscon.c | 2 +- > > > > > > > > drivers/sysreset/sysreset_watchdog.c | 40 > > > > > > > > ++-- > > > > > > > > drivers/watchdog/wdt-uclass.c| 8 ++ > > > > > > > > include/sysreset.h | 10 +++ > > > > > > > > 9 files changed, 67 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > Applied to u-boot-marvell > > > > > > > > > > > > Mmmh, why u-boot-marvell, > > > > > > > > > > Because I'm handling watchdog related changed since a few years and we > > > > > did not create a specific subsystem repo for this and I'm usually > > > > > using my "marvell" one for this. > > And fwiw, there's a few other cases like this. If it's too confusing, > maybe we should just roll out a few more repositories, I think it's > easier to do that now than pre-gitlab? > > > > > > > and why did this end up already in master? > > > > > > Isn't that material for the next merge window? After all this > > > > > > changes > > > > > > quite a bit, for a lot of boards, and I did not have a closer look > > > > > > at > > > > > > the sunxi parts yet. > > > > > > > > > > I was hesitating also a bit. But since this patchset is on the list in > > > > > v1 since over 2 months now (2021-08-21) I thought it was "ready" for > > > > > inclusion now. We are at -rc1 and I think we still have enough time to > > > > > fix any resulting problems in this release cycle. > > > > > > Why do we have the merge window then? This is clearly not a regression or > > > general fix. > > > > AFAIU, we are a bit less strict here in U-Boot. Patches that were posted > > before the merge-window and skipped the review process (most likely > > because of lack of time) are often still integrated in the early rcX > > cycles. At least this is how I handle it
Re: [PATCH 4/4] mmc: sunxi: Use DM_GPIO flags to set pull-up
On 10/21/21 06:52, Samuel Holland wrote:
Now that the sunxi_gpio driver handles pull-up/down via the driver
model, pin configuration does not need a platform-specific function.
Signed-off-by: Samuel Holland
I tested on an OrangePi PC (orangepi_pc_defconfig). The 'mmc rescan'
command detects correctly if an SD-card is present with this series applied.
Tested-by: Heinrich Schuchardt
---
drivers/mmc/sunxi_mmc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index c170c16d5a..955b29826f 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -700,12 +700,8 @@ static int sunxi_mmc_probe(struct udevice *dev)
return ret;
/* This GPIO is optional */
- if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
- GPIOD_IS_IN)) {
- int cd_pin = gpio_get_number(>cd_gpio);
-
- sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
- }
+ gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
+GPIOD_IS_IN | GPIOD_PULL_UP);
upriv->mmc = >mmc;
