May 2021 - U-Boot

[PATCH V4 1/2] mmc: add OpenPiton mmc support
by Tianrui Wei 08 May '21

08 May '21

From: Tianrui Wei <tianrui-wei(a)outlook.com> Date: Thu, 6 May 2021 11:30:20 +0800 Subject: [PATCH V4 1/2] mmc: add OpenPiton mmc support This patch adds mmc support for OpenPiton. Specifically, some dts bindings were not used because our mmc controller doens't have those configuration options, it only exposes a dummy mmap interface for CPU. Signed-off-by: Tianrui Wei <tianrui-wei(a)outlook.com> Signed-off-by: Jonathan Balkind <jbalkind(a)ucsb.edu> --- drivers/mmc/Kconfig | 7 + drivers/mmc/Makefile | 1 + drivers/mmc/piton_mmc.c | 172 +++++ 3 files changed, 180 insertions(+) create mode 100644 drivers/mmc/piton_mmc.c diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 14d79139..1038800f 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -707,6 +707,13 @@ config MMC_SUNXI_HAS_MODE_SWITCH bool depends on MMC_SUNXI +config MMC_PITON + bool "MMC support for openpiton SoC" + depends on DM_MMC && BLK + help + This driver enables SD card support in U-Boot port for + OpenPiton SoC + config GENERIC_ATMEL_MCI bool "Atmel Multimedia Card Interface support" depends on DM_MMC && BLK && ARCH_AT91 diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 1c849cba..698dfe05 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o obj-$(CONFIG_MMC_SDHCI_ZYNQ) += zynq_sdhci.o obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o +obj-$(CONFIG_MMC_PITON) += piton_mmc.o obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c new file mode 100644 index 00000000..266e26d8 --- /dev/null +++ b/drivers/mmc/piton_mmc.c @@ -0,0 +1,172 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2009 SAMSUNG Electronics + * Minkyu Kang <mk7.kang(a)samsung.com> + * Jaehoon Chung <jh80.chung(a)samsung.com> + * Portions Copyright 2011-2019 NVIDIA Corporation + * Portions Copyright 2021 Tianrui Wei + * Tianrui Wei <tianrui-wei(a)outlook.com> + */ + +#include <asm/gpio.h> +#include <asm/io.h> +#include <common.h> +#include <dm.h> +#include <errno.h> +#include <linux/bitops.h> +#include <linux/types.h> +#include <linux/delay.h> +#include <linux/err.h> +#include <log.h> +#include <div64.h> +#include <mmc.h> + +struct piton_mmc_plat { + struct mmc_config cfg; + struct mmc mmc; +}; + +struct piton_mmc_priv { + u64 piton_mmc_base_addr; /* peripheral id */ +}; + +/* + * see mmc_read_blocks to see how it is used. + * start block is hidden at cmd->arg + * also, initialize the block size at init + */ +static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd, + struct mmc_data *data) +{ + /* check first if this is a pure command */ + if (!data) + return 0; + + u64 byte_cnt = data->blocks * data->blocksize; + u64 start_block = cmd->cmdarg; + unsigned int *buff = (unsigned int *)data->dest; + + struct piton_mmc_priv *priv = dev_get_priv(dev); + u64 start_addr = priv->piton_mmc_base_addr + (start_block); + + /* if there is a read */ + if (data->flags & MMC_DATA_READ) { + for (u64 i = 0; i < byte_cnt; i += 4) { + *(buff) = readl((void *)(start_addr + i)); + buff++; + } + } else { + /* else there is a write + * we don't handle write, so error right away + */ + return -ENODEV; + } + + return 0; +} + +static int piton_mmc_ofdata_to_platdata(struct udevice *dev) +{ + struct piton_mmc_priv *priv = dev_get_priv(dev); + struct piton_mmc_plat *plat = dev_get_platdata(dev); + struct mmc_config *cfg; + struct mmc *mmc; + /* fill in device description */ + struct blk_desc *bdesc; + + priv->piton_mmc_base_addr = dev_read_addr(dev); + cfg = &plat->cfg; + cfg->name = "PITON MMC"; + cfg->host_caps = MMC_MODE_8BIT; + cfg->f_max = 100000; + cfg->f_min = 400000; + cfg->voltages = MMC_VDD_21_22; + + mmc = &plat->mmc; + mmc->read_bl_len = MMC_MAX_BLOCK_LEN; + mmc->capacity_user = 0x100000000; + mmc->capacity_user *= mmc->read_bl_len; + mmc->capacity_boot = 0; + mmc->capacity_rpmb = 0; + for (int i = 0; i < 4; i++) + mmc->capacity_gp[i] = 0; + mmc->capacity = 0x2000000000ULL; + mmc->has_init = 1; + + bdesc = mmc_get_blk_desc(mmc); + bdesc->lun = 0; + bdesc->hwpart = 0; + bdesc->type = 0; + bdesc->blksz = mmc->read_bl_len; + bdesc->log2blksz = LOG2(bdesc->blksz); + bdesc->lba = lldiv(mmc->capacity, mmc->read_bl_len); + + return 0; +} + +/* test if piton has the micro mmc card present + * always return 1, which means present + */ +static int piton_mmc_getcd(struct udevice *dev) +{ + /* + * always return 1 + */ + return 1; +} + +/* dummy function, piton_mmc don't need initialization + * in hw + */ +static const struct dm_mmc_ops piton_mmc_ops = { + .send_cmd = piton_mmc_send_cmd, + .set_ios = piton_mmc_set_ios, + .get_cd = piton_mmc_getcd, +}; + +static int piton_mmc_probe(struct udevice *dev) +{ + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); + struct piton_mmc_plat *plat = dev_get_platdata(dev); + struct mmc_config *cfg = &plat->cfg; + + cfg->name = dev->name; + upriv->mmc = &plat->mmc; + upriv->mmc->has_init = 1; + upriv->mmc->capacity = 0x2000000000ULL; + upriv->mmc->read_bl_len = MMC_MAX_BLOCK_LEN; + + return 0; +} + +static int piton_mmc_bind(struct udevice *dev) +{ + struct piton_mmc_plat *plat = dev_get_platdata(dev); + struct mmc_config *cfg = &plat->cfg; + + cfg->name = dev->name; + cfg->host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_8BIT; + cfg->voltages = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34; + cfg->f_min = 1000000; + cfg->f_max = 52000000; + cfg->b_max = U32_MAX; + + return mmc_bind(dev, &plat->mmc, cfg); +} + +static const struct udevice_id piton_mmc_ids[] = { + {.compatible = "openpiton,piton-mmc"}, + { /* sentinel */ } +}; + +U_BOOT_DRIVER(piton_mmc_drv) = { + .name = "piton_mmc", + .id = UCLASS_MMC, + .of_match = piton_mmc_ids, + .ofdata_to_platdata = piton_mmc_ofdata_to_platdata, + .bind = piton_mmc_bind, + .probe = piton_mmc_probe, + .ops = &piton_mmc_ops, + .platdata_auto_alloc_size = sizeof(struct piton_mmc_plat), + .priv_auto_alloc_size = sizeof(struct piton_mmc_priv), +}; -- 2.17.1

2 9

[PATCH v2 00/11] riscv: Switch to use binman to generate u-boot.itb
by Bin Meng 08 May '21

08 May '21

This series updates binman to handle creation of u-boot.itb image for RISC-V boards. Changes in v2: - drop patch: "binman: test: Correct the name of 170_fit_fdt_missing_prop.dts", as it was based on a wrong version - drop patch: "makefile: Update clean rule to remove files generated by binman", as it is better to refactor binman to generate all intermediate files for Makefile to clean - drop "size = <16>" in the binman node - new patch: "binman: Support packaging U-Boot for scenarios like OF_PRIOR_STAGE" - new patch: "riscv: dts: Sort build targets in alphabetical order" - new patch: "riscv: qemu: Switch to use binman to generate u-boot.itb" - new patch: "riscv: Drop USE_SPL_FIT_GENERATOR" Bin Meng (11): common: kconfig: Correct a typo in SPL_LOAD_FIT binman: Correct '-a' description in the doc binman: Correct the comment for ATF entry type binman: test: Rename 172_fit_fdt.dts to 170_fit_fdt.dts binman: Add support for RISC-V OpenSBI fw_dynamic blob makefile: Pass OpenSBI blob to binman make rules riscv: sifive: unleashed: Switch to use binman to generate u-boot.itb binman: Support packaging U-Boot for scenarios like OF_PRIOR_STAGE riscv: dts: Sort build targets in alphabetical order riscv: qemu: Switch to use binman to generate u-boot.itb riscv: Drop USE_SPL_FIT_GENERATOR Makefile | 4 +- arch/riscv/cpu/generic/Kconfig | 1 + arch/riscv/dts/Makefile | 3 +- arch/riscv/dts/binman.dtsi | 78 ++++++++++++++ .../dts/hifive-unleashed-a00-u-boot.dtsi | 1 + arch/riscv/dts/qemu-virt.dts | 8 ++ arch/riscv/lib/mkimage_fit_opensbi.sh | 100 ------------------ board/sifive/unleashed/Kconfig | 1 + common/Kconfig.boot | 5 +- configs/qemu-riscv32_spl_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 1 + dts/Kconfig | 18 ++++ lib/Kconfig | 2 +- tools/binman/binman.rst | 4 +- tools/binman/entries.rst | 13 +++ tools/binman/etype/atf_bl31.py | 2 +- tools/binman/etype/opensbi.py | 23 ++++ tools/binman/ftest.py | 17 ++- .../test/{172_fit_fdt.dts => 170_fit_fdt.dts} | 0 tools/binman/test/201_opensbi.dts | 14 +++ 20 files changed, 182 insertions(+), 114 deletions(-) create mode 100644 arch/riscv/dts/binman.dtsi create mode 100644 arch/riscv/dts/qemu-virt.dts delete mode 100755 arch/riscv/lib/mkimage_fit_opensbi.sh create mode 100644 tools/binman/etype/opensbi.py rename tools/binman/test/{172_fit_fdt.dts => 170_fit_fdt.dts} (100%) create mode 100644 tools/binman/test/201_opensbi.dts -- 2.25.1

2 21

[Question] Reloading pcie + nvme drivers
by Brian McKee 08 May '21

08 May '21

Hi Gents. Background: working with the socfpga fork of u-boot-2020.10, I've added a driver for the Altera V series FPGA PCIe controller to u-boot (borrowed completely from intel's 10 series FPGA driver and the linux kernel driver). I got it working through a series of hacks to the pcie and nvme drivers. I haven't been able to get 2021.04 Denx version to work, I think because the PCIe -> memory interface is not enabled by 'bridge enable'. I could probably hack that, but for now I'm sticking with 2020.10 socfpga. Based on my experiments though, it looks like the hacks I deployed to 2020.10 are not necessary on 2021.04. I'm waiting for socfpga to port to 2021.04. I have a problem though. To keep cost down, I have a 2MB QSPI flash device on the board. And to keep software developers happy, the almost 8 MiB FPGA image should be stored on the SSD so field upgrades are less likely to brick the hardware. I have created a stripped down FPGA that only contains the PCIe controller and the HPS module. lzma compressed it is less than 300KB. It fits quite nicely into the free space of the QSPI NOR Flash memory. I have u-boot installed on the QSPI, booting and I've setup commands to grab the stripped down FPGA image, decompress it, and load it into the FPGA. Then initialize PCI and NVME scan and it all works! However, when I reload the FPGA from the NVME, pcie is okay, but the nvme crashes. I'm not sure why. It might be getting reset by the FPGA re-load. All of it's programming disappears and it drops off the bus. I have proven that if I perform a u-boot 'reset' after the full FPGA is loaded, do a 'bridge enable', 'pci' and 'nvme scan' the nvme comes back to life using the full fpga image. I have been trying to figure out how to trick u-boot into re-initializing the nvme controller, but I haven't figured out a hack to do so yet. Ideally, I'd like to be able to unload the nvme driver (and possibly the pcie driver) and then reload them but there doesn't appear to be a way to do that in u-boot at this time. Do any of you guys have any suggestions for what I can try to reinitialize the nvme driver? Thanks much for your support. Brian

2 3

[PATCH v3 0/2] log: Allow multiple lines and conversion to printf()
by Simon Glass 08 May '21

08 May '21

At present when logging is not enabled, all log() calls become nops. This does not seem right, since if the log level is high enough then there should be some sort of message. So in that case, this series updates it to print the message if the log level is above LOGL_INFO. This mimics the behaviour for the log_...() macros like log_debug() and log_info(), so we can drop the special case for these. Also the current implementation does not support multiple log calls on the same line nicely. The tags are repeated so the line is very hard to read. This series adds that as a new feature. Changes in v3: - Rebase on hexdump series http://patchwork.ozlabs.org/project/uboot/list/?series=242818 Changes in v2: - Update commit message and cover letter to mention log_...() macros - Add a test for !CONFIG_LOG - Update log() to (effectively) call debug() for log_level == LOGL_DEBUG Simon Glass (2): sandbox: log: Avoid build error with !CONFIG_LOG log: Convert log values to printf() if not enabled configs/sandbox_defconfig | 1 + doc/develop/logging.rst | 6 ++++-- include/log.h | 34 +++++++++++++++------------------- test/log/Makefile | 2 ++ test/log/nolog_ndebug.c | 38 ++++++++++++++++++++++++++++++++++++++ test/log/nolog_test.c | 3 +++ 6 files changed, 63 insertions(+), 21 deletions(-) create mode 100644 test/log/nolog_ndebug.c -- 2.31.1.607.g51e8a6a459-goog

1 2

[PATCH] pxe_utils: add localcmd defination
by Artem Lapkin 08 May '21

08 May '21

pxe localboot usage too much limited, i think be useful improve it welcome for any suggestions and feedbacks... 1) add localcmd defination which can used with localboot by default localboot get from env, now we can define it in pxe script 2) localcmd can use without localboot 3) multiline usage for localcmd 4) add short alias ! for localcmd 5) localcmd eval as uboot script (run_command_list) 6) label + localcmd simple usage uboot pxe menu with uboot commands Usage examples # standalone usage LABEL update_uboot LOCALCMD ip=$tftpip && tftpboot $ip:boot.scr.uimg && script LABEL reset # multiline usage LOCALCMD echo RESET LOCALCMD reset LABEL reset again # multiline alias usage ! echo RESET ! reset LABEL localboot # redefile localcmd for localboot LOCALBOOT 1 LOCALCMD echo temporary redefine localcmd Signed-off-by: Artem Lapkin <art(a)khadas.com> --- cmd/pxe_utils.c | 29 ++++++++++++++++++++++++++++- cmd/pxe_utils.h | 1 + 2 files changed, 29 insertions(+), 1 deletion(-) diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c index f1ed671a..fdf532ec 100644 --- a/cmd/pxe_utils.c +++ b/cmd/pxe_utils.c @@ -271,6 +271,9 @@ static void label_destroy(struct pxe_label *label) if (label->kernel) free(label->kernel); + if (label->localcmd) + free(label->localcmd); + if (label->config) free(label->config); @@ -322,7 +325,10 @@ static int label_localboot(struct pxe_label *label) { char *localcmd; - localcmd = from_env("localcmd"); + if (label->localcmd) + localcmd = label->localcmd; + else + localcmd = from_env("localcmd"); if (!localcmd) return -ENOENT; @@ -470,6 +477,11 @@ static int label_boot(struct cmd_tbl *cmdtp, struct pxe_label *label) return 0; } + if (label->localcmd) { + if (!label->localboot_val) + return run_command_list(label->localcmd, strlen(label->localcmd), 0); + } + if (!label->kernel) { printf("No kernel given, skipping %s\n", label->name); @@ -687,6 +699,8 @@ enum token_type { T_APPEND, T_INITRD, T_LOCALBOOT, + T_LOCALCMD, + T_LOCALCMD2, T_DEFAULT, T_PROMPT, T_INCLUDE, @@ -721,6 +735,8 @@ static const struct token keywords[] = { {"kernel", T_KERNEL}, {"linux", T_LINUX}, {"localboot", T_LOCALBOOT}, + {"localcmd", T_LOCALCMD}, + {"!", T_LOCALCMD2}, {"append", T_APPEND}, {"initrd", T_INITRD}, {"include", T_INCLUDE}, @@ -1102,6 +1118,7 @@ static int parse_label(char **c, struct pxe_menu *cfg) int len; char *s = *c; struct pxe_label *label; + char *add; int err; label = label_create(); @@ -1177,6 +1194,16 @@ static int parse_label(char **c, struct pxe_menu *cfg) err = parse_integer(c, &label->localboot_val); break; + case T_LOCALCMD: + case T_LOCALCMD2: + if (label->localcmd) { + if (parse_sliteral(c, &add)) + sprintf(label->localcmd, "%s\n%s", label->localcmd, add); + } else { + err = parse_sliteral(c, &label->localcmd); + } + break; + case T_IPAPPEND: err = parse_integer(c, &label->ipappend); break; diff --git a/cmd/pxe_utils.h b/cmd/pxe_utils.h index bbdc606b..cdac1327 100644 --- a/cmd/pxe_utils.h +++ b/cmd/pxe_utils.h @@ -49,6 +49,7 @@ struct pxe_label { int attempted; int localboot; int localboot_val; + char *localcmd; struct list_head list; }; -- 2.25.1

2 1

[PATCH 0/5] Add support for embedding public key in platform's dtb
by Sughosh Ganu 08 May '21

08 May '21

Patch 1 fixes an issue of selection of IMAGE_SIGN_INFO config option when capsule authentication is enabled. Patch 2 add two config symbols, EFI_PKEY_DTB_EMBED and EFI_PKEY_FILE which are used for enabling embedding of the public key in the dtb, and specifying the esl file name. Patch 3 moves efi_capsule_auth_enabled as a weak function, which can be used as a default mechanism for checking if capsule authentication has been enabled. Patch 4 adds a default weak function for retrieving the public key from the platform's dtb. Patch 5 adds the functionality to embed the esl file into the platform's dtb during the platform build. I have tested this functionality on the STM32MP157C DK2 board. [1] - https://lists.denx.de/pipermail/u-boot/2021-March/442867.html Sughosh Ganu (5): efi_loader: Kconfig: Select IMAGE_SIGN_INFO when capsule authentication is enabled efi_loader: Kconfig: Add symbols for embedding the public key into the platform's dtb efi_capsule: Add a weak function to check whether capsule authentication is enabled efi_capsule: Add a weak function to get the public key needed for capsule authentication Makefile: Add provision for embedding public key in platform's dtb Makefile | 10 ++++++ board/emulation/common/qemu_capsule.c | 6 ---- lib/efi_loader/Kconfig | 16 ++++++++++ lib/efi_loader/efi_capsule.c | 44 ++++++++++++++++++++++++--- 4 files changed, 66 insertions(+), 10 deletions(-) -- 2.17.1

5 26

[PATCH 00/13] display_options: Start to unify print_buffer() and hexdump
by Simon Glass 08 May '21

08 May '21

At present we have two ways of showing a hex dump. Once has been in U-Boot since the dawn of time and the other was recently added from Linux. They both have their own unique features. This series makes a few changes to bring them closer together. It also adds support for logging a buffer, which is useful since it can put it through the same log drivers as other logging output. Also it adds tests, so we can check the behaviour. The code-size impact of the main part of this series is 160 bytes on Thumb2, which seems acceptable. However the final patch adds another 600 bytes or so, which is not. Simon Glass (13): console: Report an error when output buffer is exhausted test: Detect when expect_str is too small test: Convert print tests to use ut framework test: Add a test for print_buffer() display_options: Drop two spaces before the ASCII column hexdump: Move API to header file hexdump: Add support for sandbox hexdump: Support any rowsize hexdump: Allow ctrl-c to interrupt output log: Drop log_nop() functions display_options: Split print_buffer() into two functions log: Add support for logging a buffer RFC: display_options: Use print_hex_dump() for print_buffer() common/console.c | 18 +- common/log.c | 30 ++++ include/asm-generic/global_data.h | 16 +- include/console.h | 3 +- include/display_options.h | 25 +++ include/hexdump.h | 81 ++++++++- include/log.h | 49 +++-- include/test/suites.h | 1 + include/test/test.h | 4 +- lib/display_options.c | 124 ++++++++----- lib/hexdump.c | 104 +++-------- test/cmd/mem_search.c | 26 +-- test/cmd_ut.c | 2 + test/dm/rtc.c | 9 +- test/log/log_test.c | 27 +++ test/print_ut.c | 286 ++++++++++++++++++++++++------ test/ut.c | 55 +++++- 17 files changed, 628 insertions(+), 232 deletions(-) -- 2.31.0.rc2.261.g7f71774620-goog

2 15

[PATCH 00/17] misc: Some more misc patches
by Simon Glass 08 May '21

08 May '21

Various issues were discovered in getting Chromium OS verified boot running on top of coreboot, booting into U-Boot. Improvements include: - enable serial console if even coreboot doesn't - enable cache always - show the BIOS date since Chromium OS's coreboot doesn't have a version - update docs - allow SPI driver to work without a PCH - fix mtrr command when multi-processing (CONFIG_MP) is disabled - add documentation about the memory map Simon Glass (17): pci: Use const for pci_find_device_id() etc. x86: pci: Allow binding of some devices before relocation x86: Allow coreboot serial driver to guess the UART spi: ich: Don't require the PCH tpm: cr50: Drop unnecessary coral headers x86: Don't set up MTRRs if previously done x86: Update the MP constants to avoid conflicts x86: Do cache set-up by default when booting from coreboot x86: coreboot: Show the BIOS date x86: coral: Allow booting from coreboot x86: Add function comments to cb_sysinfo.h x86: coreboot: Use vendor in the Kconfig x86: coreboot: Enable the cbsysinfo command x86: coreboot: Document the memory map x86: Check ROM exists before building vboot dtoc: Check that a parent is not missing doc: Update documentation for cros-2021.04 release arch/x86/cpu/coreboot/Kconfig | 3 +- arch/x86/cpu/i386/cpu.c | 2 +- arch/x86/dts/chromebook_coral.dts | 2 +- arch/x86/dts/chromebook_samus.dts | 2 +- arch/x86/include/asm/cb_sysinfo.h | 16 ++++++ arch/x86/include/asm/mp.h | 12 +++-- arch/x86/lib/init_helpers.c | 5 +- board/coreboot/coreboot/Kconfig | 12 +++-- board/coreboot/coreboot/coreboot.c | 3 ++ board/google/chromebook_coral/coral.c | 28 ++++++++++ doc/board/coreboot/coreboot.rst | 19 +++++++ doc/chromium/run_vboot.rst | 15 +++--- doc/device-tree-bindings/pci/x86-pci.txt | 7 ++- drivers/pci/pci-uclass.c | 39 ++++++++++++-- drivers/serial/serial_coreboot.c | 68 +++++++++++++++++++++--- drivers/spi/ich.c | 4 +- drivers/tpm/cr50_i2c.c | 2 - include/dt-bindings/pci/pci.h | 12 +++++ include/pci.h | 5 +- include/pci_ids.h | 1 + tools/dtoc/dtb_platdata.py | 9 ++++ tools/dtoc/test/dtoc_test_noparent.dts | 32 +++++++++++ tools/dtoc/test_dtoc.py | 10 ++++ 23 files changed, 264 insertions(+), 44 deletions(-) create mode 100644 include/dt-bindings/pci/pci.h create mode 100644 tools/dtoc/test/dtoc_test_noparent.dts -- 2.31.0.208.g409f899ff0-goog

4 52

[PATCH 0/9] riscv: Partially move to binman to generate u-boot.itb
by Bin Meng 08 May '21

08 May '21

This series updates binman to handle creation of u-boot.itb image for RISC-V SiFive Unleashed board. QEMU RISC-V remains unchanged, as binman uses a dtb to describe the image format, but for QEMU RISC-V there is no dtb as dtb is passed to U-Boot via CONFIG_OF_PRIOR_STAGE. Not sure how such use case could be properly supported by binman? Bin Meng (9): common: kconfig: Correct a typo in SPL_LOAD_FIT binman: Correct '-a' description in the doc binman: Correct the comment for ATF entry type binman: test: Rename 172_fit_fdt.dts to 170_fit_fdt.dts binman: test: Correct the name of 170_fit_fdt_missing_prop.dts binman: Add support for RISC-V OpenSBI fw_dynamic blob makefile: Update clean rule to remove files generated by binman makefile: Pass OpenSBI blob to binman make rules riscv: sifive: unleashed: Switch to use binman to generate u-boot.itb .gitignore | 4 +- Makefile | 6 +- arch/riscv/dts/binman.dtsi | 70 +++++++++++++++++++ .../dts/hifive-unleashed-a00-u-boot.dtsi | 1 + board/sifive/unleashed/Kconfig | 1 + common/Kconfig.boot | 2 +- configs/sifive_unleashed_defconfig | 1 + tools/binman/binman.rst | 4 +- tools/binman/entries.rst | 13 ++++ tools/binman/etype/atf_bl31.py | 2 +- tools/binman/etype/opensbi.py | 23 ++++++ tools/binman/ftest.py | 17 +++-- .../test/{172_fit_fdt.dts => 170_fit_fdt.dts} | 0 tools/binman/test/201_opensbi.dts | 16 +++++ 14 files changed, 148 insertions(+), 12 deletions(-) create mode 100644 arch/riscv/dts/binman.dtsi create mode 100644 tools/binman/etype/opensbi.py rename tools/binman/test/{172_fit_fdt.dts => 170_fit_fdt.dts} (100%) create mode 100644 tools/binman/test/201_opensbi.dts -- 2.25.1

2 25

Re: [Patch v2 1/2] clk: zynq: Add clock wizard driver
by Zhengxun Li 07 May '21

07 May '21

Hi Michal, > Hi, > > snip. > >>>> + >>>> + priv->base = (void __iomem *)addr; >>> >>> But this assignment should be done in probe where you copy data from >>> plat structures to priv structures. >> >> Do you mean priv->base = (void __iomem *)plat->addr? > > yes. > > >>>> + >>>> + clk_in1 = dev_read_u32_default(dev, "clock-frequency", 0); >>> >>> This is not the part of DT binding. You should be able to get that >>> frequencies via clock framework. >> >> Can you provide some hints about this? I am new to clock driver. > > You should look at drivers/serial/serial_zynq.c where you can find out > clk_get_by_index(), clk_get_rate(), clk_enable() > > That clk_get_rate() is the function you should use to get that frequency. Thanks for your help. > snip. > >> >>>> + { /* sentinel */ } >>>> +}; >>>> + >>>> +U_BOOT_DRIVER(clk_wzrd) = { >>>> + .name = "zynq-clk-wizard", >>>> + .id = UCLASS_CLK, >>>> + .of_match = clk_wzrd_ids, >>>> + .ops = &clk_wzrd_ops, >>>> + .probe = clk_wzrd_probe, >>>> + .of_to_plat = clk_wzrd_of_to_plat, >>>> + .priv_auto = sizeof(struct clkwzd), >>> >>> you need to get memory for .plat_auto here. >> >> Okay. >> >> On the other hand, if we want to add set_phase feature to clock wizard, >> can you make some suggestions? I checked the clk-uclass and it does not >> seem to be supported. > > Then you have to add it to uclass first but don't know content here. Okay. I switched my email account, I hope the declarement didn't offend you. Thanks, Zhengxun

1 0