April 2021 - U-Boot

[GIT PULL] TI changes for v2021.07 rc1
by Lokesh Vutla 19 Apr '21

19 Apr '21

Hi Tom, Please find the PR for master branch targeted for v2021.07-rc1 release. Details about the PR are updated in the tag message. Gitlab build report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7194 The following changes since commit b46dd116ce03e235f2a7d4843c6278e1da44b5e1: Prepare v2021.04 (2021-04-05 11:03:29 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.07-rc1 for you to fetch changes up to e64665fa727eeecd04446551cee25b43f355c69e: arm: dts: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems (2021-04-16 19:09:24 +0530) ---------------------------------------------------------------- - Support for pinmux status command on beaglebone - Updates for MMC speed modes for J721e-evm - Fix MMC booting on omap35_logic_somlv board ---------------------------------------------------------------- Adam Ford (1): configs: omap35_logic_somlv: Fix MMC booting Aswath Govindraju (1): arm: dts: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems Dario Binacchi (12): pinctrl: single: fix format of structure documentation pinctrl: single: fix the loop counter variable type pinctrl: single: fix offset management pinctrl: single: fix debug messages formatting pinctrl: single: get register area size by device API pinctrl: single: check "register-width" DT property pinctrl: single: change function mask default value pinctrl: single: add register access functions pinctrl: single: add get_pins_count operation pinctrl: single: add get_pin_name operation pinctrl: single: add get_pin_muxing operation test: pinmux: add test for 'pinctrl-single' driver arch/arm/dts/k3-j721e-main.dtsi | 19 +- arch/sandbox/dts/test.dts | 72 ++++++ configs/omap35_logic_somlv_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + drivers/pinctrl/pinctrl-single.c | 474 ++++++++++++++++++++++++++++++----- test/dm/pinmux.c | 91 ++++++- 7 files changed, 590 insertions(+), 69 deletions(-) -- 2.30.0

2 1

[PATCH] env/fat.c: support redund environment
by Brandon Maier 19 Apr '21

19 Apr '21

Signed-off-by: Brandon Maier <brandon.maier(a)rockwellcollins.com> CC: Joe Hershberger <joe.hershberger(a)ni.com> CC: Wolfgang Denk <wd(a)denx.de> --- env/Kconfig | 13 +++++++++++-- env/fat.c | 41 +++++++++++++++++++++++++++++++++-------- 2 files changed, 44 insertions(+), 10 deletions(-) diff --git a/env/Kconfig b/env/Kconfig index 67ce93061b..a940ddce95 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -411,8 +411,9 @@ config ENV_IS_IN_UBI config SYS_REDUNDAND_ENVIRONMENT bool "Enable redundant environment support" - depends on ENV_IS_IN_EEPROM || ENV_IS_IN_FLASH || ENV_IS_IN_MMC || \ - ENV_IS_IN_NAND || ENV_IS_IN_SPI_FLASH || ENV_IS_IN_UBI + depends on ENV_IS_IN_EEPROM || ENV_IS_IN_FAT || ENV_IS_IN_FLASH || \ + ENV_IS_IN_MMC || ENV_IS_IN_NAND || ENV_IS_IN_SPI_FLASH || \ + ENV_IS_IN_UBI help Normally, the environemt is stored in a single location. By selecting this option, you can then define where to hold a redundant @@ -461,6 +462,14 @@ config ENV_FAT_FILE It's a string of the FAT file name. This file use to store the environment. +config ENV_FAT_FILE_REDUND + string "Name of the FAT file to use for the environment" + depends on ENV_IS_IN_FAT && SYS_REDUNDAND_ENVIRONMENT + default "uboot-redund.env" + help + It's a string of the FAT file name. This file use to store the + redundant environment. + config ENV_EXT4_INTERFACE string "Name of the block device for the environment" depends on ENV_IS_IN_EXT4 diff --git a/env/fat.c b/env/fat.c index 653a38fd93..e4cd5970b4 100644 --- a/env/fat.c +++ b/env/fat.c @@ -29,6 +29,10 @@ # define LOADENV #endif +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT +DECLARE_GLOBAL_DATA_PTR; +#endif + static char *env_fat_device_and_part(void) { #ifdef CONFIG_MMC @@ -53,6 +57,7 @@ static int env_fat_save(void) env_t __aligned(ARCH_DMA_MINALIGN) env_new; struct blk_desc *dev_desc = NULL; struct disk_partition info; + const char *file = CONFIG_ENV_FAT_FILE; int dev, part; int err; loff_t size; @@ -78,29 +83,41 @@ static int env_fat_save(void) return 1; } - err = file_fat_write(CONFIG_ENV_FAT_FILE, (void *)&env_new, 0, sizeof(env_t), - &size); +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT + if (gd->env_valid == ENV_VALID) + file = CONFIG_ENV_FAT_FILE_REDUND; +#endif + + err = file_fat_write(file, (void *)&env_new, 0, sizeof(env_t), &size); if (err == -1) { /* * This printf is embedded in the messages from env_save that * will calling it. The missing \n is intentional. */ printf("Unable to write \"%s\" from %s%d:%d... ", - CONFIG_ENV_FAT_FILE, CONFIG_ENV_FAT_INTERFACE, dev, part); + file, CONFIG_ENV_FAT_INTERFACE, dev, part); return 1; } +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT + gd->env_valid = (gd->env_valid == ENV_REDUND) ? ENV_VALID : ENV_REDUND; +#endif + return 0; } #ifdef LOADENV static int env_fat_load(void) { - ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE); + ALLOC_CACHE_ALIGN_BUFFER(char, buf1, CONFIG_ENV_SIZE); +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT + ALLOC_CACHE_ALIGN_BUFFER(char, buf2, CONFIG_ENV_SIZE); + int err2; +#endif struct blk_desc *dev_desc = NULL; struct disk_partition info; int dev, part; - int err; + int err1; #ifdef CONFIG_MMC if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc")) @@ -124,8 +141,15 @@ static int env_fat_load(void) goto err_env_relocate; } - err = file_fat_read(CONFIG_ENV_FAT_FILE, buf, CONFIG_ENV_SIZE); - if (err == -1) { + err1 = file_fat_read(CONFIG_ENV_FAT_FILE, buf1, CONFIG_ENV_SIZE); +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT + err2 = file_fat_read(CONFIG_ENV_FAT_FILE_REDUND, buf2, CONFIG_ENV_SIZE); + + err1 = (err1 >= 0) ? 0 : -1; + err2 = (err2 >= 0) ? 0 : -1; + return env_import_redund(buf1, err1, buf2, err2, H_EXTERNAL); +#else + if (err1 < 0) { /* * This printf is embedded in the messages from env_save that * will calling it. The missing \n is intentional. @@ -135,7 +159,8 @@ static int env_fat_load(void) goto err_env_relocate; } - return env_import(buf, 1, H_EXTERNAL); + return env_import(buf1, 1, H_EXTERNAL); +#endif err_env_relocate: env_set_default(NULL, 0); -- 2.29.1

3 2

pcie + nvme + cyclone V
by Brian McKee 18 Apr '21

18 Apr '21

Hello all. I'm trying to get an NVMe device to work with a PCIe hard core in an Altera (intel) Cyclone V SOC from u-boot. It is working well in linux. I have been hacking on u-boot for about a week and have drawn some conclusions that may or may not be accurate. First, let me give you some background. In linux, the device tree description for the pcie module looks like this: bridges: bridge@c0000000 { compatible = "altr,bridge-20.1", "simple-bus"; reg = <0xc0000000 0x20000000>, <0xff200000 0x00200000>; reg-names = "axi_h2f", "axi_h2f_lw"; clocks = <&pcie &pll_65 &pcie &pll_65>; clock-names = "h2f_axi_clock", "h2f_lw_axi_clock", "f2h_sdram0_clock", "f2h_sdram1_clock"; #address-cells = <2>; #size-cells = <1>; ranges = <0x00000000 0x00200080 0xc0200080 0x00000010>, <0x00000000 0x00200000 0xc0200000 0x00000080>, <0x00000000 0x00000000 0xc0000000 0x00100000>, <0x00000000 0x00100000 0xc0100000 0x00004000>, <0x00000001 0x00000000 0xff200000 0x00100000>; pcie: pcie@000100000 { // The @000100000 signifies nothing! compatible = "altr,pcie-root-port-20.1", "altr,pcie-root-port-1.0"; reg = <0x00000000 0x00000000 0x00100000>, <0x00000000 0x00100000 0x00004000>; reg-names = "Txs", "Cra"; interrupt-parent = <&intc>; interrupts = <0 40 4>; // 40 is the interrupt, add 32 to relate to the GIC document interrupt-controller; // 4 is IRQ_TYPE_LEVEL_HIGH, 1 is IRQ_TYPE_EDGE_RISING #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; #clock-cells = <0>; clocks = <&clk_100>; device_type = "pci"; bus-range = <0x00 0xff>; ranges = <0x82000000 0x0 0x00000000 0x0 0x00000000 0x0 0x00100000>; msi-parent = <&msi>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie 1>, <0 0 0 2 &pcie 2>, <0 0 0 3 &pcie 3>, <0 0 0 4 &pcie 4>; status = "disabled"; // Disabled by default }; //end pcie@000100000 msi: msi@000200080 { compatible = "altr,msi-1.0"; reg = <0x00000000 0x00200080 0x00000010>, <0x00000000 0x00200000 0x00000080>; reg-names = "csr", "vector_slave"; interrupt-parent = <&intc>; interrupts = <0 41 4>; clocks = <&pll_65>; msi-controller = <1>; num-vectors = <32>; status = "disabled"; // Disabled by default }; //end msi@000200080 }; //end bridge@c0000000 (bridges) Sorry, the indenting was lost. That portion of socfpga.dtsi works in linux. BUS 1 BAR 0 of the PCIe controller is programmed correctly, offset 0x10 gets an address of 0x00000000 and CPU space is mapped to 0xc0000000. However, from what I can tell, u-boot can't handle the hierarchical nature of "simple-bus". It doesn't know how to or the two addresses to get a resultant CPU memory base address. That's not a big problem, because I can flatten the tree to look like this: pcie: pcie@000100000 { compatible = "altr,pcie-root-port-1.0"; reg = <0x00000000 0x00100000>, <0xC0100000 0x00004000>; reg-names = "Txs", "Cra"; interrupt-parent = <&intc>; interrupts = <0 40 4>; // 40 is the interrupt, add 32 to relate to the GIC document interrupt-controller; // 4 is IRQ_TYPE_LEVEL_HIGH, 1 is IRQ_TYPE_EDGE_RISING #address-cells = <2>; #size-cells = <1>; #interrupt-cells = <1>; #clock-cells = <0>; clocks = <&clk_100>; device_type = "pci"; bus-range = <0x00 0xff>; ranges = <0x82000000 0x00000000 0xc0000000 0x00100000>; // <32BITNOPF> <PCI ADDR> <HOSTADDR> <MEM SIZE> msi-parent = <&msi>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie 1>, <0 0 0 2 &pcie 2>, <0 0 0 3 &pcie 3>, <0 0 0 4 &pcie 4>; }; //end pcie@000100000 msi: msi@C0200080 { compatible = "altr,msi-1.0"; reg = <0x0 0xC0200080 0x00000010>, <0x0 0xC0200000 0x00000080>; reg-names = "csr", "vector_slave"; interrupt-parent = <&intc>; interrupts = <0 41 4>; clocks = <&pll_65>; msi-controller = <1>; num-vectors = <32>; }; //end msi@000200080 However, this does not work either. The PCI driver becomes confused by the ranges description: I think because it does not understand that the pci device perspective can be different from the CPU perspective. It can't find the memory described in the ranges variable and I get debug output (plus printfs that I added) that looks like this: pciauto_setup_device: bars_num = 6 cfg_dword_read: bus=1, byte_en=0x3, offset=0x0004, data=0x00100000 cfg_dword_write: bus=1, byte_en=0xf, offset=0x0010, data=0xffffffff cfg_dword_read: bus=1, byte_en=0xf, offset=0x0010, data=0xffffc004 bar_response = 0xffffc004 PCI address space is 64 bit. cfg_dword_write: bus=1, byte_en=0xf, offset=0x0014, data=0xffffffff cfg_dword_read: bus=1, byte_en=0xf, offset=0x0014, data=0xffffffff PCI Autoconfig: BAR 0, Mem, size=0x4000 res->bus_lower = 0x0, size = 0x4000, res->size = 0x100000 addr = 0x0, res->bus_start = 0xc0000000 No room in resource, avail start=0 / size=100000, need=4000 PCI: Failed autoconfig bar 0 bar_value = 0xffffffff I have hacked pci_auto to get the correct values programmed into BUS 1 BAR 0, however, the nvme driver chokes when it goes and looks for the memory indicated by BUS 1 BAR 0 and can't find it because the NVMe driver (pci driver, actually?) needs to be aware of the different mapping of the PCI address space and CPU address space for the PCIe controller. It looks at location 0x00000000 in the ranges variable and only sees 0xc0000000. Frankly, I'm hoping I'm doing it wrong and you guys can come back and say, "you're doing it all wrong, do this instead..." But in the event that my hunches are correct, I'm hoping you guys could give me directions on what code needs to change to support this sort of configuration. With a little direction, I can figure out how to change it and submit the code back to you guys for approval. Any assistance will be greatly appreciated. Thanks.

1 0

[RFC PATCH 0/2] env: sf: remove the static env_flash variable
by Patrick Delaunay 18 Apr '21

18 Apr '21

Proposal to cleanup the SPI device support in env/sf.c, after the question of mail [1]. Release the SPI flash after each ENV request, so U-Boot can't have conflict of other SPI user. This serie can be applied on top on previous serie [2]. Drawback: possible performance issue as SPI device is probed/release for each ENV access when several ENV opts are called. [1] Mail "Question about env_flash variable in env/sf.c" Dec 17, 2020; 6:33pm http://u-boot.10912.n7.nabble.com/Question-about-env-flash-variable-in-env-… [2] env: sf: add support of command env erase http://patchwork.ozlabs.org/project/uboot/list/?series=228696&state=* Patrick Patrick Delaunay (2): env: sf: add missing spi_flash_free env: sf: remove the static env_flash variable env/sf.c | 44 ++++++++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 20 deletions(-) -- 2.17.1

2 4

[PATCH resend 0/2] add CONFIG_ENV_SECT_SIZE_AUTO
by Rasmus Villemoes 18 Apr '21

18 Apr '21

This is a resend, just rebased to current master, of patches I sent way back in May. This is roughly the U-Boot side equivalent to commit e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl), at least for SPI_FLASH backend. When CONFIG_ENV_SECT_SIZE_AUTO is not selected (and it is of course default n), there's no functional change, and the compiler even seems to generate identical binary code. The motivation is to cut about half a second off boottime on our newer revisions, while still having the same U-Boot binary work on both. Rasmus Villemoes (2): env/sf.c: use a variable to hold the sector size env: add CONFIG_ENV_SECT_SIZE_AUTO env/Kconfig | 14 ++++++++++++++ env/sf.c | 32 ++++++++++++++++++++------------ 2 files changed, 34 insertions(+), 12 deletions(-) -- 2.29.2

2 4

[PATCH 0/3] env: sf: add support of command env erase
by Patrick Delaunay 18 Apr '21

18 Apr '21

Hi, I add support of env erase command for SPI flash backend (sf). To erase the environment, this patch only invalidate the content at CONFIG_ENV_OFFSET and at CONFIG_ENV_OFFSET_REDUND (force a bad CRC). The 2 first patchs of the serie are preliminary and clenaup steps. Patrick Patrick Delaunay (3): env: add ENV_ERASE_PTR macro env: sf: update the use of macro ENV_SAVE_PTR env: sf: add support of command env erase env/ext4.c | 3 +-- env/mmc.c | 6 +----- env/sf.c | 36 +++++++++++++++++++++++++++++++++++- include/env_internal.h | 1 + 4 files changed, 38 insertions(+), 8 deletions(-) -- 2.17.1

2 6

[PATCH V3] env: Fix invalid env handling in env_init()
by Marek Vasut 18 Apr '21

18 Apr '21

This fixes the case where there are multiple environment drivers, one of them is the default environment one, and it is followed by an environment driver which does not implement .init() callback. The default environment driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init() callback implementation, which is valid behavior for default environment. Since the subsequent environment driver does not implement .init(), it also does not modify the $ret variable in the loop. Therefore, the loop is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the code further down in env_init() will not reset the environment to the default one, which is incorrect. This patch sets the $ret variable back to -ENOENT in case the env_valid is set to ENV_INVALID by an environment driver, so that the environment would be correctly reset back to default one, unless a subsequent driver loads a valid environment. Signed-off-by: Marek Vasut <marex(a)denx.de> --- V2: Reword commit message V3: Rebase --- env/env.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/env/env.c b/env/env.c index 37b4b54cb75..7faa7ab661b 100644 --- a/env/env.c +++ b/env/env.c @@ -334,6 +334,9 @@ int env_init(void) debug("%s: Environment %s init done (ret=%d)\n", __func__, drv->name, ret); + + if (gd->env_valid == ENV_INVALID) + ret = -ENOENT; } if (!prio) -- 2.29.2

3 3

[PATCH] env: Fix warning when forcing environment without ENV_ACCESS_IGNORE_FORCE
by Martin Fuzzey 18 Apr '21

18 Apr '21

Since commit 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set") a warning message is displayed when setenv -f is used WITHOUT CONFIG_ENV_ACCESS_IGNORE_FORCE, but the variable is set anyway, resulting in lots of log pollution. env_flags_validate() returns 0 if the access is accepted, or non zero if it is refused. So the original code #ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE if (flag & H_FORCE) return 0; #endif was correct, it returns 0 (accepts the modification) if forced UNLESS IGNORE_FORCE is set (in which case access checks in the following code are applied). The broken patch just added a printf to the force accepted case. To obtain the intent of the patch we need this: if (flag & H_FORCE) { #ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE printf("## Error: Can't force access to \"%s\"\n", name); #else return 0; #endif } Fixes: 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set") Signed-off-by: Martin Fuzzey <martin.fuzzey(a)flowbird.group> --- env/flags.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/env/flags.c b/env/flags.c index df4aed2..e3e833c 100644 --- a/env/flags.c +++ b/env/flags.c @@ -563,12 +563,13 @@ int env_flags_validate(const struct env_entry *item, const char *newval, return 1; #endif -#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE if (flag & H_FORCE) { +#ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE printf("## Error: Can't force access to \"%s\"\n", name); +#else return 0; - } #endif + } switch (op) { case env_op_delete: if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_DELETE) { -- 1.9.1

5 14

[PATCH] env: increment redund flag on read fail
by Brandon Maier 18 Apr '21

18 Apr '21

If one of the reads fails when importing redundant environments (a single read failure), the env_flags wouldn't get initialized in env_import_redund(). If a user then calls saveenv, the new environment will have the wrong flags value. So on the next load the new environment will be ignored. While debugging this, I also noticed that env/sf.c was not correctly handling a single read failure, as it would not check the crc before assigning it to gd->env_addr. Having a special error path for when there is a single read failure seems unnecessary and may lead to future bugs. Instead collapse the 'single read failure' error to be the same as a 'single crc failure'. That way env_check_redund() either passes or fails, and if it passes we are guaranteed to have checked the CRC. Signed-off-by: Brandon Maier <brandon.maier(a)rockwellcollins.com> CC: Joe Hershberger <joe.hershberger(a)ni.com> CC: Wolfgang Denk <wd(a)denx.de> CC: Heiko Schocher <hs(a)denx.de> --- env/common.c | 27 ++++++++------------------- env/sf.c | 2 +- include/env.h | 2 -- 3 files changed, 9 insertions(+), 22 deletions(-) diff --git a/env/common.c b/env/common.c index 6c32a9b479..ca22885fa4 100644 --- a/env/common.c +++ b/env/common.c @@ -144,7 +144,7 @@ static unsigned char env_flags; int env_check_redund(const char *buf1, int buf1_read_fail, const char *buf2, int buf2_read_fail) { - int crc1_ok, crc2_ok; + int crc1_ok = 0, crc2_ok = 0; env_t *tmp_env1, *tmp_env2; tmp_env1 = (env_t *)buf1; @@ -152,25 +152,18 @@ int env_check_redund(const char *buf1, int buf1_read_fail, if (buf1_read_fail && buf2_read_fail) { puts("*** Error - No Valid Environment Area found\n"); + return -EIO; } else if (buf1_read_fail || buf2_read_fail) { puts("*** Warning - some problems detected "); puts("reading environment; recovered successfully\n"); } - if (buf1_read_fail && buf2_read_fail) { - return -EIO; - } else if (!buf1_read_fail && buf2_read_fail) { - gd->env_valid = ENV_VALID; - return -EINVAL; - } else if (buf1_read_fail && !buf2_read_fail) { - gd->env_valid = ENV_REDUND; - return -ENOENT; - } - - crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) == - tmp_env1->crc; - crc2_ok = crc32(0, tmp_env2->data, ENV_SIZE) == - tmp_env2->crc; + if (!buf1_read_fail) + crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) == + tmp_env1->crc; + if (!buf2_read_fail) + crc2_ok = crc32(0, tmp_env2->data, ENV_SIZE) == + tmp_env2->crc; if (!crc1_ok && !crc2_ok) { return -ENOMSG; /* needed for env_load() */ @@ -207,10 +200,6 @@ int env_import_redund(const char *buf1, int buf1_read_fail, if (ret == -EIO) { env_set_default("bad env area", 0); return -EIO; - } else if (ret == -EINVAL) { - return env_import((char *)buf1, 1, flags); - } else if (ret == -ENOENT) { - return env_import((char *)buf2, 1, flags); } else if (ret == -ENOMSG) { env_set_default("bad CRC", 0); return -ENOMSG; diff --git a/env/sf.c b/env/sf.c index 91ed2860ed..1102b42804 100644 --- a/env/sf.c +++ b/env/sf.c @@ -350,7 +350,7 @@ static int env_sf_init_early(void) ret = env_check_redund((char *)tmp_env1, read1_fail, (char *)tmp_env2, read2_fail); - if (ret == -EIO || ret == -ENOMSG) + if (ret < 0) goto err_read; if (gd->env_valid == ENV_VALID) diff --git a/include/env.h b/include/env.h index c15339a93f..b5731e4b9a 100644 --- a/include/env.h +++ b/include/env.h @@ -328,8 +328,6 @@ int env_export(struct environment_s *env_out); * @buf2_read_fail: 0 if buf2 is valid, non-zero if invalid * @return 0 if OK, * -EIO if no environment is valid, - * -EINVAL if read of second entry is good - * -ENOENT if read of first entry is good * -ENOMSG if the CRC was bad */ -- 2.29.1

2 2

[GIT PULL] sunxi: First changes for v2021.07 merge window
by Andre Przywara 18 Apr '21

18 Apr '21

Hi Tom, please pull this branch, containing the first part of the 2021.07 changes. This adds support for devices with R40 dual rank DRAM, and asymmetric A64 DRAM devices like the Pinephone/3GB. Also we enable automatic gzipped kernel support, and allow scripted DT overlay support. The rest of the patches are cleanups, but also some sunxi-specific preparatory patches for USB3.0 and improved HDMI support. The bulk of those changes will go through other trees, though. Build-tested for all 156 sunxi boards, and boot tested on a A64, A20, R40, H5, H6 and H616 board. USB, SD card, eMMC, HDMI and Ethernet all work there (where applicable), with the exception of Ethernet on the H5. Since this is already broken in v2021.04, I will send a separate fix. Thanks, Andre ============== The following changes since commit 45b3cf88da24206a6cb847efe837fddc120af3e8: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq (2021-04-15 13:11:19 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to 599177ed5139dbab112d0c9603e18382d0c642ba: sunxi: video: select dw-hdmi in Kconfig, not Makefile (2021-04-16 01:12:59 +0100) ---------------------------------------------------------------- Arnaud Ferraris (1): sunxi: arm64: Add addresses for compressed kernel load Icenowy Zheng (2): sunxi: support asymmetric dual rank DRAM on A64/R40 sunxi: enable dual rank memory on R40 Jernej Skrabec (2): sunxi: add fdtoverlay_addr_r environment variable sunxi: video: select dw-hdmi in Kconfig, not Makefile Samuel Holland (4): clk: sunxi: Add a dummy clock driver for the RTC clk: sunxi: h6: Add XHCI clocks sunxi: binman: Respect the default FIT configuration sunxi: binman: Do not hardcode U-Boot load address arch/arm/dts/sunxi-u-boot.dtsi | 4 +- arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h | 11 +- arch/arm/mach-sunxi/Kconfig | 1 + arch/arm/mach-sunxi/dram_sunxi_dw.c | 149 +++++++++++++++++++----- drivers/clk/sunxi/Makefile | 2 + drivers/clk/sunxi/clk_h6.c | 2 + drivers/clk/sunxi/clk_sun6i_rtc.c | 35 ++++++ drivers/video/sunxi/Makefile | 2 +- include/configs/sunxi-common.h | 64 ++++++---- 9 files changed, 215 insertions(+), 55 deletions(-) create mode 100644 drivers/clk/sunxi/clk_sun6i_rtc.c

2 1