November 2021 - U-Boot

[PATCH v3 00/35] efi: Improvements to U-Boot running on top of UEFI
by Simon Glass 04 Nov '21

04 Nov '21

At present U-Boot can be built as an EFI app, but it is really just for testing, with very few features. Instead, the payload build is used for booting on top of UEFI, where U-Boot takes over the machine immediately and supplies its own drivers. But the app could be made more useful. This series provides access to EFI block devices and the video console within U-Boot. It also restructures the app to make it possible to boot a kernel, although further work is needed to implement this. This can be thought of as making U-Boot perform a little like 'grub', in that it runs purely based on UEFI-provided services. Of course a lot more work is required, but this is a start. Note: It would be very useful to include qemu tests of the app and stub in CI. This is available at u-boot-dm/efi-working Changes in v3: - Add new patch to show the system-table revision - Default to 256MB of RAM for U-Boot instead of 32MB - Drop comments that confuse sphinx - Fix 'complicating' typo - Move device_path path change to its own patch - Update minimum RAM to 256MB! - s/qemu/QEMU/ Changes in v2: - Add MAINTAINERS entry - Add a better boot command too - Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used - Add a sentence about what the patch does - Add a work-around to avoid a toolchain crash - Add new patch to drop the OF_EMBED warning for EFI - Add new patch to enable DM_ETH for the app - Add new patch to support the efi command in the app - Add support for creating a partition table with a filesystem inside - Add support for running qemu with just a serial console (no display) - Drop mention of partitions from the commit message - Expand the commit message to make things clearer - Fix 'as' typo - Show the correct interface type with 'part list' - Update documentation - Update the commit message to explain things better - Use log_info() instead of printf() Simon Glass (35): efi: Add a script for building and testing U-Boot on UEFI efi: Enable DM_ETH for the app efi: Drop the OF_EMBED warning for EFI x86: Create a 32/64-bit selection for the app efi: Create a 64-bit app x86: Don't duplicate global_ptr in 64-bit EFI app efi: Add a way to obtain boot services in the app efi: Add video support to the app efi: Add EFI uclass for media efi: Add a media/block driver for EFI block devices efi: Locate all block devices in the app patman: Use a ValueError exception if tools.Run() fails binman: Report an error if test files fail to compile binman: Support reading the offset of an ELF-file symbol binman: Allow timeout to occur in the image or its section binman: Tidy up comments on _DoTestFile() binman: Support updating the dtb in an ELF file efi: serial: Support arrow keys bloblist: Support allocating the bloblist x86: Allow booting a kernel from the EFI app x86: Don't process the kernel command line unless enabled x86: efi: Add room for the binman definition in the dtb efi: Drop device_path from struct efi_priv efi: Add comments to struct efi_priv efi: Fix ll_boot_init() operation with the app efi: Add a few comments to the stub efi: Share struct efi_priv between the app and stub code efi: Move exit_boot_services into a function efi: Check for failure when initing the app efi: Mention that efi_info_get() is only used in the stub efi: Show when allocated pages are used efi: Allow easy selection of serial-only operation efi: Update efi_get_next_mem_desc() to avoid needing a map efi: Support the efi command in the app efi: Show the system-table revision MAINTAINERS | 7 + Makefile | 10 +- arch/sandbox/dts/test.dts | 4 + arch/x86/cpu/efi/payload.c | 17 +- arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/cpu/u-boot-64.lds | 2 + arch/x86/cpu/x86_64/Makefile | 4 + arch/x86/cpu/x86_64/cpu.c | 32 +- arch/x86/cpu/x86_64/misc.c | 41 +++ arch/x86/dts/Makefile | 2 +- arch/x86/dts/efi-x86_app.dts | 4 + arch/x86/lib/bootm.c | 11 +- arch/x86/lib/zimage.c | 13 +- board/efi/Kconfig | 15 +- board/efi/efi-x86_app/Kconfig | 6 +- board/efi/efi-x86_app/MAINTAINERS | 11 +- cmd/Makefile | 2 +- cmd/efi.c | 78 +++-- common/Kconfig | 15 +- common/bloblist.c | 16 +- common/board_f.c | 8 +- ..._app_defconfig => efi-x86_app32_defconfig} | 3 +- configs/efi-x86_app64_defconfig | 39 +++ disk/part.c | 5 +- doc/develop/bloblist.rst | 16 + doc/develop/uefi/u-boot_on_efi.rst | 74 ++++- drivers/block/Kconfig | 33 +++ drivers/block/Makefile | 4 + drivers/block/blk-uclass.c | 2 +- drivers/block/efi-media-uclass.c | 15 + drivers/block/efi_blk.c | 115 ++++++++ drivers/block/sb_efi_media.c | 20 ++ drivers/serial/serial_efi.c | 11 +- drivers/video/Kconfig | 2 +- drivers/video/efi.c | 45 ++- include/configs/efi-x86_app.h | 31 +- include/dm/uclass-id.h | 1 + include/efi.h | 121 +++++++- include/efi_api.h | 15 + include/init.h | 2 +- lib/efi/Kconfig | 34 ++- lib/efi/efi.c | 106 +++++++ lib/efi/efi_app.c | 276 +++++++++++++++++- lib/efi/efi_stub.c | 95 +++--- scripts/build-efi.sh | 193 ++++++++++++ test/dm/Makefile | 1 + test/dm/efi_media.c | 24 ++ tools/binman/binman.rst | 36 +++ tools/binman/cmdline.py | 2 + tools/binman/control.py | 11 + tools/binman/elf.py | 74 ++++- tools/binman/elf_test.py | 45 ++- tools/binman/ftest.py | 91 +++++- tools/binman/test/Makefile | 13 +- tools/binman/test/bss_data.c | 2 +- tools/binman/test/embed_data.c | 16 + tools/binman/test/embed_data.lds | 23 ++ tools/binman/test/u_boot_binman_embed.c | 13 + tools/binman/test/u_boot_binman_embed.lds | 29 ++ tools/binman/test/u_boot_binman_embed_sm.c | 13 + tools/patman/tools.py | 2 +- 61 files changed, 1746 insertions(+), 207 deletions(-) create mode 100644 arch/x86/cpu/x86_64/misc.c rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (94%) create mode 100644 configs/efi-x86_app64_defconfig create mode 100644 drivers/block/efi-media-uclass.c create mode 100644 drivers/block/efi_blk.c create mode 100644 drivers/block/sb_efi_media.c create mode 100755 scripts/build-efi.sh create mode 100644 test/dm/efi_media.c create mode 100644 tools/binman/test/embed_data.c create mode 100644 tools/binman/test/embed_data.lds create mode 100644 tools/binman/test/u_boot_binman_embed.c create mode 100644 tools/binman/test/u_boot_binman_embed.lds create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c -- 2.33.0.1079.g6e70778dc9-goog

2 44

[PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config
by Simon Glass 04 Nov '21

04 Nov '21

U-Boot makes use of the devicetree for its driver model. Devices are bound based on the hardware description in the devicetree. Since U-Boot is not an operating system, it has no command line or user space to provide configuration and policy information. This must be made available in some other way. Therefore U-Boot uses devicetree for configuration and run-time control and has done for approximately 9 years. This works extremely well in the project and is very flexible. However the bindings have never been incorporated in the devicetree bindings in the Linux tree. This could be a good time to start this work as we try to create standard bindings for communicating between firmware components. Add an initial binding for this node, covering just the config node, which is the main requirement. It is similar in concept to the chosen node, but used for passing information between firmware components, instead of from firmware to operating system. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Please be kind in your review. Some words about why this is needed are included in the description in config.yaml file. The last attempt to add just one property needed by U-Boot went into the weeds 6 years ago, with what I see as confusion about the role of the chosen node in devicetree[1]. I am trying again in the hope of reaching resolution rather than just going around in circles with the 'devicetree is a hardware description' argument :-) Quoting from the introduction to latest devicetree spec[2]: >>> To initialize and boot a computer system, various software components interact. Firmware might perform low-level initialization of the system hardware before passing control to software such as an operating system, bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, load and transfer control to operating systems. Standard, consistent interfaces and conventions facilitate the interactions between these software components. In this document the term boot program is used to generically refer to a software component that initializes the system state and executes another software component referred to as a client program. <<< This clearly envisages multiple software components in the firmware domain and in fact that is the case today. They need some way to communicate configuration data such as memory setup, runtime-feature selection and developer conveniences. Devicetree seems ideal, at least for components where the performance / memory requirements of devicetree are affordable. I hope that the Linux community (which owns the devicetree bindings) finds this initiative valuable and acceptable. [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html [2] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 .../devicetree/bindings/u-boot/config.yaml | 137 ++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml b/Documentation/devicetree/bindings/u-boot/config.yaml new file mode 100644 index 00000000000000..336577a17fdf5a --- /dev/null +++ b/Documentation/devicetree/bindings/u-boot/config.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/u-boot/config.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot configuration node + +maintainers: + - Simon Glass <sjg(a)chromium.org> + +description: | + The config node does not represent a real device, but serves as a place + for passing data between firmware elements, like memory maps. Data in the + config node does not represent the hardware. It is ignored by operating + systems. + + Purpose of config node + ---------------------- + + A common problem with firmware is that many builds are needed to deal with the + slight variations between different, related models. For example, one model + may have a TPM and another may not. Devicetree provides an excellent solution + to this problem, in that the devicetree to actually use on a platform can be + injected in the factory based on which model is being manufactured at the time. + + A related problem causing build proliferation is dealing with the differences + between development firmware, developer-friendly firmware (e.g. with all + security features present but with the ability to access the command line), + test firmware (which runs tests used in the factory), final production + firmware (before signing), signed firmware (where the signatures have been + inserted) and the like. Ideally all or most of these should use the same + U-Boot build, with just some options to determine the features available. For + example, being able to control whether the UART console or JTAG are available, + on any image, is a great debugging aid. + + When the firmware consists of multiple parts (various U-Boot phases, TF-A, + OP-TEE), it is helpful that all operate the same way at runtime, regardless of + how they were built. This can be achieved by passing the runtime configuration + (e.g. 'enable UART console', 'here are your public keys') along the chain + through each firmware stage. It is frustrating to have to replicate a bug on + production firmware which does happen on developer firmware, because they are + completely different builds. + + The config node provides useful functionality for this. It allows the different + controls to be 'factored out' of the U-Boot binary, so they can be controlled + separately from the initial source-code build. The node can be easily updated + by a build or factory tool and can control various features in U-Boot. It is + similar in concept to a Kconfig option, except that it can be changed after + U-Boot is built. + + The config node is similar in concept to /chosen (see chosen.txt) except that + it is for passing information *into* and *between) firmware components, + instead of from firmware to the Operating System. Also, while operating + systems typically have a (sometimes extremely long) command line, U-Boot does + not support this, except with sandbox. The devicetree provides a more + structured approach in any case. + +properties: + + compatible: + enum: + - "u-boot,config" + + bootcmd: + $ref: /schemas/types.yaml#/definitions/string + description: | + Allows overwriting of the boot command used by U-Boot on startup. If + present, U-Boot uses this command instead. Note that this feature can + work even if loading the environment is disabled, e.g. for security + reasons. See also bootsecure. + + bootdelay: + $ref: /schemas/types.yaml#/definitions/int32 + description: | + Allows selecting of the U-Boot bootdelay, to control whether U-Boot + waits on boot or for how long. This allows this option to be configured + by the build system or by a previous-stage binary. For example, if the + images is being packed for testing or a user holds down a button, it may + allow a delay, but disable it for production. + + If this property is not present, a default value is used instead. + + Values: + + -1: no bootdelay and the user cannot interrupt boot + 0: no bootdelay but use user can still interrupt boot by holding down a + key, if enabled + >= 1: delay for this many seconds + + + bootsecure: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Controls the execution of the boot command in U-Boot, e.g. selecting + between using a special function to run commands, or the normal CLI. This + can be used in production images, to restrict the amount of parsing done + or the options available, to cut back on the available surface for + security attacks. + + Values: + + 0: normal boot using CLI (default if not present) + 1: use secure boot mechanism instead to parse and run commands + other values are reserved for future use + 2: use simplified command line (e.g. avoid hush) + 3... reserved + + silent-console: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + This allows the console to be silenced by default on boot. This can allow + easy disabling of console output on a production build, for example. When + suppressed, the console is still active. This feature only suppresses the + console output itself, on all output devices. + + Values: + + 0: console output appears as normal (default) + 1: console output is suppressed but console recording still operates (if + enabled) + 2: console output is suppressed and not recorded + +required: + - compatible + +additionalProperties: false + +examples: + - | + u-boot,config { + compatible = "u-boot,config"; + bootcmd = "vboot go auto"; + bootdelay = <(-1)>; + bootsecure = <1>; + silent-console = <1>; + }; -- 2.33.0.800.g4c38ced690-goog

3 11

[PATCH 1/1] board: ae350: Support autoboot from RAM
by Leo Yu-Chi Liang 04 Nov '21

04 Nov '21

Add boot command "bootcmd_ram" to support autoboot from RAM. This feature could be useful at the very initial state of chip design when there is only a minimal set of peripheral. (e.g. without mmc and mac ..etc) The kernel image is default to be loaded at 0x2000000 via debug port, and the following script serves as an example: spl() { cmd="riscv64-linux-gdb -q \ -ex \"target remote $host:$port\" \ -ex \"load\" \ -ex \"thread apply all set \\\$pc=&_start\" \ -ex \"thread apply all set \\\$a0=\\\$mhartid\" \ -ex \"thread apply all set \\\$a1=<dtb address>\" \ -ex \"restore u-boot.itb binary 0x200000\" \ -ex \"restore Image binary 0x2000000\" \ -ex \"c\" \ spl/u-boot-spl " echo $cmd eval $cmd } The address where the kernel is loaded can be altered by changing the value of KERNEL_IMAGE_ADDR. Signed-off-by: Leo Yu-Chi Liang <ycliang(a)andestech.com> --- include/configs/ax25-ae350.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h index bf3f34e428..1c3f957d32 100644 --- a/include/configs/ax25-ae350.h +++ b/include/configs/ax25-ae350.h @@ -119,12 +119,23 @@ /* Increase max gunzip size */ #define CONFIG_SYS_BOOTM_LEN (64 << 20) +/* Support autoboot from RAM (kernel image is loaded via debug port) */ +#define KERNEL_IMAGE_ADDR "0x2000000 " +#define BOOTENV_DEV_NAME_RAM(devtypeu, devtypel, instance) \ + "ram " +#define BOOTENV_DEV_RAM(devtypeu, devtypel, instance) \ + "bootcmd_ram=" \ + "booti " \ + KERNEL_IMAGE_ADDR \ + "- $fdtcontroladdr\0" + /* When we use RAM as ENV */ /* Enable distro boot */ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ - func(DHCP, dhcp, na) + func(DHCP, dhcp, na) \ + func(RAM, ram, na) #include <config_distro_bootcmd.h> #define CONFIG_EXTRA_ENV_SETTINGS \ -- 2.17.0

1 0

[PATCH v3 0/3] Enhance Measured Boot
by Masahisa Kojima 04 Nov '21

04 Nov '21

This patch series add the following measurement mandated in the TCG PC Client PFP Specification. - SMBIOS tables - GPT disk partition topology - AuditMode and Deployed mode Masahisa Kojima (3): efi_loader: add SMBIOS table measurement efi_loader: add UEFI GPT measurement efi_loader: add DeployedMode and AuditMode variable measurement include/blk.h | 3 + include/efi_loader.h | 5 +- include/efi_tcg2.h | 27 +++ include/smbios.h | 17 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_boottime.c | 4 +- lib/efi_loader/efi_device_path.c | 27 +++ lib/efi_loader/efi_smbios.c | 2 - lib/efi_loader/efi_tcg2.c | 297 ++++++++++++++++++++++++++++++- lib/smbios-parser.c | 152 ++++++++++++++-- 10 files changed, 518 insertions(+), 17 deletions(-) -- 2.17.1

4 20

Commit 76c2ff3e broke backlight on Chromebook snow
by Guillaume GARDET 03 Nov '21

03 Nov '21

Hi, Commit 76c2ff3e [0] broke backlight on Chromebook snow. A revert on top of 2021.10 restores the backlight. Not sure why it breaks on Chromebook snow yet. Dario, any idea how to fix this? Cheers, Guillaume

3 5

[PATCH] driver: gadget: fastboot: Link endpoint and descriptors
by qianfanguijin＠163.com 03 Nov '21

03 Nov '21

From: qianfan Zhao <qianfanguijin(a)163.com> If the downloading file size is equal to the partition size, "fastboot flash" can't work, at least in sunxi platform, because used an uninitalized point: ep->desc. Reproduce: fastboot flash loader1 spl/sunxi-spl.bin. Fix it. Signed-off-by: qianfan Zhao <qianfanguijin(a)163.com> --- drivers/usb/gadget/f_fastboot.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 8ba55aab9f..45bb3aba66 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -319,13 +319,13 @@ static int fastboot_set_alt(struct usb_function *f, struct usb_composite_dev *cdev = f->config->cdev; struct usb_gadget *gadget = cdev->gadget; struct f_fastboot *f_fb = func_to_fastboot(f); - const struct usb_endpoint_descriptor *d; debug("%s: func: %s intf: %d alt: %d\n", __func__, f->name, interface, alt); - d = fb_ep_desc(gadget, &fs_ep_out, &hs_ep_out, &ss_ep_out); - ret = usb_ep_enable(f_fb->out_ep, d); + f_fb->out_ep->desc = fb_ep_desc(gadget, &fs_ep_out, &hs_ep_out, + &ss_ep_out); + ret = usb_ep_enable(f_fb->out_ep, f_fb->out_ep->desc); if (ret) { puts("failed to enable out ep\n"); return ret; @@ -339,8 +339,8 @@ static int fastboot_set_alt(struct usb_function *f, } f_fb->out_req->complete = rx_handler_command; - d = fb_ep_desc(gadget, &fs_ep_in, &hs_ep_in, &ss_ep_in); - ret = usb_ep_enable(f_fb->in_ep, d); + f_fb->in_ep->desc = fb_ep_desc(gadget, &fs_ep_in, &hs_ep_in, &ss_ep_in); + ret = usb_ep_enable(f_fb->in_ep, f_fb->in_ep->desc); if (ret) { puts("failed to enable in ep\n"); goto err; -- 2.17.1

2 1

[PATCH 0/3] mtd: spi-nor-core: Add support for mx66lm1g45g
by Tudor Ambarus 03 Nov '21

03 Nov '21

Add support for mx66lm1g45g: - Introduce SPI_NOR_SOFT_RESET flash_info flag -> the flash does not define the SFDP tables and can't determine its reset sequence on its own. - Fix the opcode extension for the software reset sequence -> it was hardcoded. Tudor Ambarus (3): mtd: spi-nor-core: Introduce SPI_NOR_SOFT_RESET flash_info flag mtd: spi-nor-core: macronix: Add support for mx66lm1g45g mtd: spi-nor-core: Fix the opcode extension for the software reset sequence drivers/mtd/spi/Kconfig | 8 +++ drivers/mtd/spi/sf_internal.h | 5 ++ drivers/mtd/spi/spi-nor-core.c | 89 ++++++++++++++++++++++++++++++---- drivers/mtd/spi/spi-nor-ids.c | 6 +++ include/linux/mtd/spi-nor.h | 8 +++ 5 files changed, 107 insertions(+), 9 deletions(-) -- 2.25.1

1 3

[PULL] u-boot-usb/master
by Marek Vasut 03 Nov '21

03 Nov '21

The following changes since commit b8bfe05282c12fbf006957a2564127d3c1be3e78: Merge tag 'u-boot-amlogic-20211102' of https://source.denx.de/u-boot/custodians/u-boot-amlogic (2021-11-02 08:56:42 -0400) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to 2c4f21763d7132bc355d343347032bd6d2f199f4: usb: mtu3: flush cache for the first GPD when allocate GPD ring (2021-11-03 08:47:57 +0100) ---------------------------------------------------------------- Chunfeng Yun (1): usb: mtu3: flush cache for the first GPD when allocate GPD ring drivers/usb/mtu3/mtu3_qmu.c | 1 + 1 file changed, 1 insertion(+)

2 1

Please pull u-boot-marvell/master
by Stefan Roese 03 Nov '21

03 Nov '21

Hi Tom, please pull this next batch of Marvell MVEBU related patches: ---------------------------------------------------------------- - pci_mvebu: Fix access to config space and PCIe Root Port (Pali) - a37xx: pci: Program the data strobe for config read requests (Pali) - kwboot: Misc improvements and fixes (Pali) ---------------------------------------------------------------- Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=130&view=results Thanks, Stefan The following changes since commit a79115dde373f7cdb181040dd6489fd0b21bfbd2: Prepare v2022.01-rc1 (2021-11-01 15:16:43 -0400) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 57fa6fb93291cdcabc1c38d874d12257a879f8ee: arm: a37xx: pci: Program the data strobe for config read requests (2021-11-03 06:45:34 +0100) ---------------------------------------------------------------- Pali Rohár (28): pci: pci_mvebu: Fix write_config() with PCI_SIZE_8 or PCI_SIZE_16 pci: pci_mvebu: Fix read_config() with PCI_SIZE_8 or PCI_SIZE_16 pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port) pci: pci_mvebu: Remove unused functions pci: pci_mvebu: Fix place of link up detection pci: pci_mvebu: Do not automatically enable bus mastering on PCI Bridge pci: pci_mvebu: Setup PCI controller to Root Complex mode pci: pci_mvebu: Fix comment about driver class name tools: kwboot: Initialize rfds to zero tools: kwboot: Fix initialization of tty device tools: kwboot: Reserve enough space for patching kwbimage in memory tools: kwboot: Validate 4-byte image data checksum tools: kwboot: Inject baudrate change back code after data part tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code tools: kwboot: Correctly set configuration of UART for BootROM messages tools: kwboot: Show verbose message when waiting for baudrate change magic tools: kwboot: Simplify code for aligning image header tools: kwboot: Do not modify kwbimage header before increasing its size tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr() tools: kwboot: Change retry loop from decreasing to increasing tools: kwboot: Resend first 3 xmodem retry packets immediately tools: kwboot: Fix sending retry of last header packet tools: kwboot: Do not call tcdrain() after each sent packet tools: kwboot: Increase delay after changing baudrate in ARM code tools: kwboot: Replace ARM mov + movt instruction pair by mov + orr tools: kwboot: Do not use stack when setting baudrate back to default value tools: kwboot: Do not send magic seq when changing baudrate back to 115200 arm: a37xx: pci: Program the data strobe for config read requests drivers/pci/pci-aardvark.c | 3 + drivers/pci/pci_mvebu.c | 275 ++++++++++++++++++++++-------- tools/kwboot.c | 407 +++++++++++++++++++++++++++------------------ 3 files changed, 451 insertions(+), 234 deletions(-)

2 1

[PATCH v2 0/6] Improved sysreset/watchdog uclass integration
by Samuel Holland 03 Nov '21

03 Nov '21

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 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 | 5 ++++ include/sysreset.h | 14 ++++++++++ 9 files changed, 68 insertions(+), 13 deletions(-) -- 2.32.0

3 10