Re: [PATCH] env: Remove misuse of env is nowhere driver
Hello Stefan,
On 28.04.23 15:45, Stefan Herbrechtsmeier wrote:
> From: Stefan Herbrechtsmeier
>
> When using a list of writeable variables, the initial values come from
> the built-in default environment since commit 5ab81058364b
> ("env: Complete generic support for writable list"). Remove unnecessary
> misuse of the env is nowhere driver as default environment.
>
> Signed-off-by: Stefan Herbrechtsmeier
> ---
>
> board/aristainetos/aristainetos.c| 19 ---
> configs/aristainetos2c_defconfig | 1 -
> configs/aristainetos2ccslb_defconfig | 1 -
> env/env.c| 2 --
> 4 files changed, 23 deletions(-)
NACK.
You completely break the protected environment functionality
for the aristainetos board when you remove env_get_location()
Does it build anymore?
Also you mix up a change in common code and in board code.
And grepping in code for ENVL_NOWHERE has much more finds...
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH] buildman: Pass -Werror to the host compiler too
On Fri, Apr 28, 2023 at 01:50:48PM -0600, Simon Glass wrote: > The host compiler is not failing on warnings at present, when the > -E flag is used in buildman. Add the required flag to fix this. > > Signed-off-by: Simon Glass Since I reported this with a CI build that didn't fail, I can see now it does work: https://source.denx.de/u-boot/u-boot/-/jobs/619681 Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v8] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2023-04-28, Vagrant Cascadian wrote: > On 2023-02-05, Vagrant Cascadian wrote: >> On 2023-02-06, Patrick Wildt wrote: >>> The MNT Reform 2 is a modular DIY laptop. In its initial version it >>> is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been >>> lifted from BoundaryDevices official U-Boot downstream project. >>> >>> Signed-off-by: Patrick Wildt >> >> Tested booting Debian with a 6.1.x linux kernel on a mnt/reform2 using >> nvme rootfs and microsd /boot. Some oddities with video and wifi that do >> not occur with the vendor u-boot, but seems like huge progress. > > The patch still applies to master; could this be considered for merging > soon? I've also verified that the patch not only builds, but actually boots, based on git commit c9c2c95d4cd27fe0cd41fe13a863899d268f973c (and also works on v2023.04, for good measure)... Tested-by: Vagrant Cascadian live well, vagrant >>> --- >>> Changes since v7: >>> - Re-added lost ramdisk_addr_r. >>> Changes since v6: >>> - Cleaned up some CONFIG_* pollution. >>> Changes since v5: >>> - Adjusted to further Binman changes. >>> - Adjusted to further Kconfig conversions. >>> - Removed some phy init in favor of DM. >>> - Removed some pinmux which are now handled by DM_SERIAL. >>> - Compared with Librem5/EVK and adjusted for similarity. >>> Changes since v4: >>> - Adjusted to Kconfig conversions. >>> - Removed U-Boot-specific device tree changes. >>> - Synced device tree to Linux v5.19-rc3. >>> Changes since v3: >>> - Adjusted to Binman changes in main branch. >>> - Cleaned up environment variables akin to i.MX8MM. >>> - Added vendor-prefix to device tree filename. >>> - Provided ramdisk_addr_r. >>> Changes since v2: >>> - Switched to Binman. >>> Changes since v1: >>> - Synced DTS with files in Linux git repo. >>> - Added support for USB host ports. >>> >>> arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + >>> arch/arm/mach-imx/imx8m/Kconfig |7 + >>> board/mntre/imx8mq_reform2/Kconfig| 15 + >>> board/mntre/imx8mq_reform2/MAINTAINERS|7 + >>> board/mntre/imx8mq_reform2/Makefile | 12 + >>> board/mntre/imx8mq_reform2/imx8mq_reform2.c | 171 +++ >>> board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 + >>> .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ >>> board/mntre/imx8mq_reform2/spl.c | 260 + >>> configs/imx8mq_reform2_defconfig | 107 ++ >>> include/configs/imx8mq_reform2.h | 67 ++ >>> 11 files changed, 1766 insertions(+) >>> create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi >>> create mode 100644 board/mntre/imx8mq_reform2/Kconfig >>> create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS >>> create mode 100644 board/mntre/imx8mq_reform2/Makefile >>> create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c >>> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c >>> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h >>> create mode 100644 board/mntre/imx8mq_reform2/spl.c >>> create mode 100644 configs/imx8mq_reform2_defconfig >>> create mode 100644 include/configs/imx8mq_reform2.h signature.asc Description: PGP signature
Re: [PATCH 16/18] bootstd: Add a simple bootmeth for ChromiumOS
Hi Heinrich, On Fri, 28 Apr 2023 at 13:51, Heinrich Schuchardt wrote: > > On 4/28/23 21:18, Simon Glass wrote: > > It is possible to boot x86-based ChromeOS machines by parsing a table and > > locating the kernel and command line. Add a bootmeth for this. > > What is missing for booting ChromeOS on arm64? Well it uses FIT, but apart from that, not much, probably. I wanted to get this in before the merge window, so tried not to bite off too much. I will see what it takes to get this running on Bob and send a follow-up. Regards, Simon
Re: [PATCH 1/1] doc: man-page for cp
Hi Heinrich, On Fri, 28 Apr 2023 at 13:43, Heinrich Schuchardt wrote: > > > > On 4/28/23 21:21, Simon Glass wrote: > > Hi Heinrich, > > > > On Fri, 28 Apr 2023 at 01:41, Heinrich Schuchardt > > wrote: > >> > >> Add a man-page for the cp command. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> doc/usage/cmd/cp.rst | 83 > >> doc/usage/index.rst | 1 + > >> 2 files changed, 84 insertions(+) > >> create mode 100644 doc/usage/cmd/cp.rst > >> > >> diff --git a/doc/usage/cmd/cp.rst b/doc/usage/cmd/cp.rst > >> new file mode 100644 > >> index 00..897c0bb7df > >> --- /dev/null > >> +++ b/doc/usage/cmd/cp.rst > >> @@ -0,0 +1,83 @@ > >> +.. SPDX-License-Identifier: GPL-2.0+: > >> + > >> +cp command > >> +== > >> + > >> +Synopsis > >> + > >> + > >> +:: > >> + > >> +mm source target count > >> +mm.b source target count > >> +mm.w source target count > >> +mm.l source target count > >> +mm.q source target count > > > > Is this the cp or the mm command? > > Thanks for reviewing. It must be cp. > > > > > I think it is better to do: > > > > mm. > > > > or something like that, to avoid repetition > > We cannot completely avoid repetition as 'cp' without postfix exists. > With size I would associate a number. > Having to look into multiple places to find out that there is a cp.q > form is not helpful. You could do: cp[.b | w | l | q] I suppose But I agree it is a bit painful cp[.] might be better > > I think the current format is the easiest way to see at a glance how to > use the command. > > > > >> + > >> +Description > >> +--- > >> + > >> +The cp command is used to copy *count* words of memory from the *source* > > > > To me it is confusing to use the term 'words' here. A word typically > > means a machine word in a computer, e.g. 32- or 64-bits. > > > > How about just referring to 'transfer size' or 'access size'? > > When hearing 'transfer size' I would think of the total number of bytes > being transferred. How about 'chunk'? It is better than word or transfer size, yes. But chunk seems like a group of things and isn't quite right, I think. Do you not like 'access size'? If not, then chunk is OK I suppose. Regards, Simon
[RFC] power: imx8m-power-domain: Add delay to align with kernel driver
From: Fabio Estevam
In the imx8m power domain kernel driver, there is an extra udelay(5)
prior to requesting the domain to power up:
https://github.com/torvalds/linux/blob/v6.3/drivers/soc/imx/gpcv2.c#L347-L375
Haven't observed any issues due to the lack of this delay
in U-Boot, but better to align it with the driver implementation.
Signed-off-by: Fabio Estevam
---
Marking it as RFC for now, to try to get some feedback first.
Thanks
drivers/power/domain/imx8m-power-domain.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/power/domain/imx8m-power-domain.c
b/drivers/power/domain/imx8m-power-domain.c
index 145f6ec0cd32..df5d7d695621 100644
--- a/drivers/power/domain/imx8m-power-domain.c
+++ b/drivers/power/domain/imx8m-power-domain.c
@@ -338,6 +338,9 @@ static int imx8m_power_domain_on(struct power_domain
*power_domain)
}
}
+ /* delay for reset to propagate */
+ udelay(5);
+
if (domain->bits.pxx) {
/* request the domain to power up */
setbits_le32(base + regs->pup, domain->bits.pxx);
--
2.34.1
Re: [PATCH 16/18] bootstd: Add a simple bootmeth for ChromiumOS
On 4/28/23 21:18, Simon Glass wrote:
It is possible to boot x86-based ChromeOS machines by parsing a table and
locating the kernel and command line. Add a bootmeth for this.
What is missing for booting ChromeOS on arm64?
Best regards
Heinrich
Signed-off-by: Simon Glass
---
boot/Kconfig | 11 ++
boot/Makefile| 1 +
boot/bootmeth_cros.c | 212 +++
configs/tools-only_defconfig | 1 +
4 files changed, 225 insertions(+)
create mode 100644 boot/bootmeth_cros.c
diff --git a/boot/Kconfig b/boot/Kconfig
index d95a2a70266..1dadd42f15e 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -462,6 +462,17 @@ config BOOTMETH_GLOBAL
EFI bootmgr, since they take full control over which bootdevs are
selected to boot.
+config BOOTMETH_CROS
+ bool "Bootdev support for Chromium OS"
+ depends on X86 || SANDBOX
+ default y
+ help
+ Enables support for booting Chromium OS using bootdevs. This uses the
+ kernel A slot and obtains the kernel command line from the parameters
+ provided there.
+
+ Note that only x86 devices are supported at present.
+
config BOOTMETH_DISTRO
bool "Bootdev support for distro boot"
select PXE_UTILS
diff --git a/boot/Makefile b/boot/Makefile
index 88193a1b60e..998a7f9c684 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO) += bootmeth_distro.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO_PXE) += bootmeth_pxe.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_CROS) += bootmeth_cros.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o
ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
new file mode 100644
index 000..440737060fd
--- /dev/null
+++ b/boot/bootmeth_cros.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootmethod for ChromiumOS
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef CONFIG_X86
+#include
+#endif
+#include
+
+enum {
+ /* Offsets in the kernel-partition header */
+ KERN_START = 0x4f0,
+ KERN_SIZE = 0x518,
+
+ SETUP_OFFSET= 0x1000, /* bytes before base */
+ CMDLINE_OFFSET = 0x2000, /* bytes before base */
+ OFFSET_BASE = 0x10, /* assumed kernel load-address */
+};
+
+static int cros_check(struct udevice *dev, struct bootflow_iter *iter)
+{
+ /* This only works on block and network devices */
+ if (bootflow_iter_check_blk(iter))
+ return log_msg_ret("blk", -ENOTSUPP);
+
+ return 0;
+}
+
+static int copy_cmdline(const char *from, const char *uuid, char **bufp)
+{
+ const int maxlen = 2048;
+ char buf[maxlen];
+ char *cmd, *to, *end;
+ int len;
+
+ /* Allow space for cmdline + UUID */
+ len = strnlen(from, sizeof(buf));
+ if (len >= maxlen)
+ return -E2BIG;
+
+ log_debug("uuid %d %s\n", uuid ? (int)strlen(uuid) : 0, uuid);
+ for (to = buf, end = buf + maxlen - UUID_STR_LEN - 1; *from; from++) {
+ if (to >= end)
+ return -E2BIG;
+ if (from[0] == '%' && from[1] == 'U' && uuid &&
+ strlen(uuid) == UUID_STR_LEN) {
+ strcpy(to, uuid);
+ to += UUID_STR_LEN;
+ from++;
+ } else {
+ *to++ = *from;
+ }
+ }
+ *to = '\0';
+ len = to - buf;
+ cmd = strdup(buf);
+ if (!cmd)
+ return -ENOMEM;
+ free(*bufp);
+ *bufp = cmd;
+
+ return 0;
+}
+
+static int cros_read_bootflow(struct udevice *dev, struct bootflow *bflow)
+{
+ struct blk_desc *desc = dev_get_uclass_plat(bflow->blk);
+ ulong base, start, size, setup, cmdline, num_blks, kern_base;
+ struct disk_partition info;
+ const char *uuid = NULL;
+ void *buf, *hdr;
+ int ret;
+
+ log_debug("starting, part=%d\n", bflow->part);
+
+ /* We consider the whole disk, not any one partition */
+ if (bflow->part)
+ return log_msg_ret("max", -ENOENT);
+
+ /* Check partition 2 */
+ ret = part_get_info(desc, 2, );
+ if (ret)
+ return log_msg_ret("part", ret);
+
+ /* Make a buffer for the header information */
+ num_blks = SZ_4K >> desc->log2blksz;
+ log_debug("Reading header, blk=%s, start=%lx, blocks=%lx\n",
+ bflow->blk->name, (ulong)info.start, num_blks);
+ hdr =
[PATCH] buildman: Pass -Werror to the host compiler too
The host compiler is not failing on warnings at present, when the
-E flag is used in buildman. Add the required flag to fix this.
Signed-off-by: Simon Glass
---
tools/buildman/builderthread.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 879ff138ad7..635865c21c8 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -253,6 +253,7 @@ class BuilderThread(threading.Thread):
args.extend(['-j', str(self.builder.num_jobs)])
if self.builder.warnings_as_errors:
args.append('KCFLAGS=-Werror')
+args.append('HOSTCFLAGS=-Werror')
if self.builder.allow_missing:
args.append('BINMAN_ALLOW_MISSING=1')
if self.builder.no_lto:
--
2.40.1.495.gc816e09b53d-goog
Re: [PATCH 1/1] doc: man-page for cp
On 4/28/23 21:21, Simon Glass wrote: Hi Heinrich, On Fri, 28 Apr 2023 at 01:41, Heinrich Schuchardt wrote: Add a man-page for the cp command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/cp.rst | 83 doc/usage/index.rst | 1 + 2 files changed, 84 insertions(+) create mode 100644 doc/usage/cmd/cp.rst diff --git a/doc/usage/cmd/cp.rst b/doc/usage/cmd/cp.rst new file mode 100644 index 00..897c0bb7df --- /dev/null +++ b/doc/usage/cmd/cp.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +cp command +== + +Synopsis + + +:: + +mm source target count +mm.b source target count +mm.w source target count +mm.l source target count +mm.q source target count Is this the cp or the mm command? Thanks for reviewing. It must be cp. I think it is better to do: mm. or something like that, to avoid repetition We cannot completely avoid repetition as 'cp' without postfix exists. With size I would associate a number. Having to look into multiple places to find out that there is a cp.q form is not helpful. I think the current format is the easiest way to see at a glance how to use the command. + +Description +--- + +The cp command is used to copy *count* words of memory from the *source* To me it is confusing to use the term 'words' here. A word typically means a machine word in a computer, e.g. 32- or 64-bits. How about just referring to 'transfer size' or 'access size'? When hearing 'transfer size' I would think of the total number of bytes being transferred. How about 'chunk'? Best regards Heinrich +address to the *target* address. If the *target* address points to NOR flash, +the flash is programmed. + +The word size is defined by the suffix defaulting to 32 bits: + +== +suffix word size +== +.b 8 bit words +.w 16 bit words +.l 32 bit words +.q 64 bit words + 32 bit words +== + +source +source address, hexadecimal + +target +target address, hexadecimal + +count +number of words to be copied, hexadecimal + +Examples + + +The example device has a NOR flash where the lower part of the flash is +protected. We first copy to RAM, then to unprotected flash. Last we try to +write to protectd flash. + +:: + +=> mtd list +List of MTD devices: +* nor0 + - device: flash@0 + - parent: root_driver + - driver: cfi_flash + - path: /flash@0 + - type: NOR flash + - block size: 0x2 bytes + - min I/O: 0x1 bytes + - 0x-0x0200 : "nor0" +=> cp.b 402 500 20 +=> cp.b 402 1e0 2 +Copy to Flash... done +=> cp.b 402 0 2 +Copy to Flash... Can't write to protected Flash sectors +=> + +Configuration +- + +The cp command is available if CONFIG_CMD_MEMORY=y. Support for 64 bit words +(cp.q) depends on CONFIG_MEM_SUPPORT_64BIT_DATA=y. Copying to flash depends on +CONFIG_MTD_NOR_FLASH=y. + +Return value + + +The return value $? is set to 0 (true) if the command was successfully, +1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index cdf710919a..0fde130a54 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -41,6 +41,7 @@ Shell commands cmd/cmp cmd/coninfo cmd/conitrace + cmd/cp cmd/cyclic cmd/dm cmd/ebtupdate -- 2.39.2 Regards, Simon
Re: [PATCH v9] core: fdtaddr: use map_sysmem() as cast for the return
Hi Johan, On Fri, 28 Apr 2023 at 13:20, Simon Glass wrote: > > On Sun, 23 Apr 2023 at 03:19, Johan Jonker wrote: > > > > For the devfdt_get_addr_index_ptr() and devfdt_get_addr_size_index_ptr() > > function use map_sysmem() function as cast for the return for use in > > sandbox. Also fix sandbox test. > > > > Signed-off-by: Johan Jonker > > --- > > > > Apply after: > > [PATCH v8 00/24] Fixes for Rockchip NFC driver part 1 > > with replacement: > > [PATCH v9] core: fdtaddr: add devfdt_get_addr_size_index_ptr function > > > > --- > > > > Changed V9: > > New patch. > > Split use of map_sysmem() from previous series. > > --- > > drivers/core/fdtaddr.c | 11 +-- > > test/dm/test-fdt.c | 5 - > > 2 files changed, 13 insertions(+), 3 deletions(-) > > > > Reviewed-by: Simon Glass > > Thanks for digging into this. > > Applied to u-boot-dm, thanks! I had to drop the second hunk here since it conflicted and it looks like it was already done upstream. Please take a look and send a follow-up patch if needed. Regards, Simon
[PATCH 12/18] bootstd: Add support for updating elements of the cmdline
Add a bootflow command to update the command line more easily. This allows
changing a particular parameter rather than editing a very long strings.
It is also easier to handle with scripting.
The new 'bootflow cmdline' command allows getting and setting single
parameters.
Fix up the example output while we are here, since there are a few new
items.
Signed-off-by: Simon Glass
---
boot/bootflow.c| 53 ++
cmd/bootflow.c | 57 ++-
doc/usage/cmd/bootflow.rst | 22 +++-
include/bootflow.h | 42 ++
test/boot/bootflow.c | 109 +
5 files changed, 281 insertions(+), 2 deletions(-)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 7e2442a9599..dbf93701cfb 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -789,3 +789,56 @@ int cmdline_set_arg(char *buf, int maxlen, const char
*cmdline,
return to - buf;
}
+
+int bootflow_cmdline_set_arg(struct bootflow *bflow, const char *set_arg,
+const char *new_val, bool set_env)
+{
+ char buf[2048];
+ char *cmd = NULL;
+ int ret;
+
+ ret = cmdline_set_arg(buf, sizeof(buf), bflow->cmdline, set_arg,
+ new_val, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = bootflow_cmdline_set(bflow, buf);
+ if (*buf) {
+ cmd = strdup(buf);
+ if (!cmd)
+ return -ENOMEM;
+ }
+ free(bflow->cmdline);
+ bflow->cmdline = cmd;
+
+ if (set_env) {
+ ret = env_set("bootargs", bflow->cmdline);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+int cmdline_get_arg(const char *cmdline, const char *arg, int *posp)
+{
+ int ret;
+
+ ret = cmdline_set_arg(NULL, 1, cmdline, arg, NULL, posp);
+
+ return ret;
+}
+
+int bootflow_cmdline_get_arg(struct bootflow *bflow, const char *arg,
+const char **val)
+{
+ int ret;
+ int pos;
+
+ ret = cmdline_get_arg(bflow->cmdline, arg, );
+ if (ret < 0)
+ return ret;
+ *val = bflow->cmdline + pos;
+
+ return ret;
+}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index 155c71f83c2..dc54124621c 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -431,6 +431,59 @@ static int do_bootflow_menu(struct cmd_tbl *cmdtp, int
flag, int argc,
return 0;
}
+
+static int do_bootflow_cmdline(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct bootstd_priv *std;
+ struct bootflow *bflow;
+ const char *op, *arg, *val = NULL;
+ int ret;
+
+ if (argc < 3)
+ return CMD_RET_USAGE;
+
+ ret = bootstd_get_priv();
+ if (ret)
+ return CMD_RET_FAILURE;
+
+ bflow = std->cur_bootflow;
+ if (!bflow) {
+ printf("No bootflow selected\n");
+ return CMD_RET_FAILURE;
+ }
+
+ op = argv[1];
+ arg = argv[2];
+ if (*op == 's') {
+ if (argc < 4)
+ return CMD_RET_USAGE;
+ val = argv[3];
+ }
+
+ switch (*op) {
+ case 'c': /* clear */
+ val = "";
+ fallthrough;
+ case 's': /* set */
+ case 'd': /* delete */
+ ret = bootflow_cmdline_set_arg(bflow, arg, val, true);
+ break;
+ case 'g': /* get */
+ ret = bootflow_cmdline_get_arg(bflow, arg, );
+ if (ret < 0)
+ printf("Cannot read arg (err %dE)\n", ret);
+ else
+ printf("%.*s\n", ret, val);
+ break;
+ }
+ if (ret < 0) {
+ printf("Operation failed\n");
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
#endif /* CONFIG_CMD_BOOTFLOW_FULL */
#ifdef CONFIG_SYS_LONGHELP
@@ -441,7 +494,8 @@ static char bootflow_help_text[] =
"bootflow select [|] - select a bootflow\n"
"bootflow info [-d] - show info on current bootflow (-d
dump bootflow)\n"
"bootflow boot - boot current bootflow (or first
available if none selected)\n"
- "bootflow menu [-t] - show a menu of available bootflows";
+ "bootflow menu [-t] - show a menu of available bootflows\n"
+ "bootflow cmdline [set|get|clear|delete] [] - update
cmdline";
#else
"scan - boot first available bootflow\n";
#endif
@@ -455,5 +509,6 @@ U_BOOT_CMD_WITH_SUBCMDS(bootflow, "Boot flows",
bootflow_help_text,
U_BOOT_SUBCMD_MKENT(info, 2, 1, do_bootflow_info),
U_BOOT_SUBCMD_MKENT(boot, 1, 1, do_bootflow_boot),
U_BOOT_SUBCMD_MKENT(menu, 2, 1, do_bootflow_menu),
+ U_BOOT_SUBCMD_MKENT(cmdline, 4, 1, do_bootflow_cmdline),
[PATCH 07/18] bootstd: Use the bootargs env var for changing the cmdline
The "bootargs" environment variable is used to set the command-line
arguments to pass to the OS. Use this same mechanism with bootstd as well.
When the variable is updated, it is written to the current bootflow. When
the current bootflow is updated, the environment variable is updated too.
Signed-off-by: Simon Glass
---
boot/bootflow.c| 59 ++
cmd/bootflow.c | 6 +
include/env_callback.h | 6 +++--
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 487552fa28c..62b7f45ab27 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -552,3 +553,61 @@ int bootflow_iter_check_system(const struct bootflow_iter
*iter)
return -ENOTSUPP;
}
+
+/**
+ * bootflow_cmdline_set() - Set the command line for a bootflow
+ *
+ * @value: New command-line string
+ * Returns 0 if OK, -ENOENT if no current bootflow, -ENOMEM if out of memory
+ */
+int bootflow_cmdline_set(struct bootflow *bflow, const char *value)
+{
+ char *cmdline = NULL;
+
+ if (value) {
+ cmdline = strdup(value);
+ if (!cmdline)
+ return -ENOMEM;
+ }
+
+ free(bflow->cmdline);
+ bflow->cmdline = cmdline;
+
+ return 0;
+}
+
+#ifdef CONFIG_BOOTSTD_FULL
+/**
+ * on_bootargs() - Update the cmdline of a bootflow
+ */
+static int on_bootargs(const char *name, const char *value, enum env_op op,
+ int flags)
+{
+ struct bootstd_priv *std;
+ struct bootflow *bflow;
+ int ret;
+
+ ret = bootstd_get_priv();
+ if (ret)
+ return 0;
+ bflow = std->cur_bootflow;
+ if (!bflow)
+ return 0;
+
+ switch (op) {
+ case env_op_create:
+ case env_op_overwrite:
+ ret = bootflow_cmdline_set(bflow, value);
+ if (ret && ret != ENOENT)
+ return 1;
+ return 0;
+ case env_op_delete:
+ bootflow_cmdline_set(bflow, NULL);
+ fallthrough;
+ default:
+ return 0;
+ }
+}
+U_BOOT_ENV_CALLBACK(bootargs, on_bootargs);
+#endif
+
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index 59d1bdc25b7..b20d5893632 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -288,6 +288,12 @@ static int do_bootflow_select(struct cmd_tbl *cmdtp, int
flag, int argc,
return CMD_RET_FAILURE;
}
std->cur_bootflow = found;
+ if (IS_ENABLED(CONFIG_BOOTSTD_FULL)) {
+ if (env_set("bootargs", found->cmdline)) {
+ printf("Cannot set bootargs\n");
+ return CMD_RET_FAILURE;
+ }
+ }
return 0;
}
diff --git a/include/env_callback.h b/include/env_callback.h
index a9a14f2a84a..23bc650c162 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -60,8 +60,10 @@
#define NET6_CALLBACKS
#endif
-#ifdef CONFIG_BOOTSTD
-#define BOOTSTD_CALLBACK "bootmeths:bootmeths,"
+#ifdef CONFIG_BOOTSTD_FULL
+#define BOOTSTD_CALLBACK \
+ "bootmeths:bootmeths," \
+ "bootargs:bootargs,"
#else
#define BOOTSTD_CALLBACK
#endif
--
2.40.1.495.gc816e09b53d-goog
[PATCH 11/18] bootstd: Add a function to update a command line
The Linux command line consists of a number of words with optional values.
At present U-Boot allows this to be changed using the bootargs environment
variable.
But this is quite painful, since the command line can be very long.
Add a function which can adjust a single field in the command line, so
that it is easier to make changes before booting.
Signed-off-by: Simon Glass
---
boot/bootflow.c | 178 +++
include/bootflow.h | 40 ++
test/boot/bootflow.c | 154 +
3 files changed, 372 insertions(+)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 62b7f45ab27..7e2442a9599 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -611,3 +611,181 @@ static int on_bootargs(const char *name, const char
*value, enum env_op op,
U_BOOT_ENV_CALLBACK(bootargs, on_bootargs);
#endif
+static int copy_in(char *buf, char *end, const char *arg, int len,
+ const char *new_val)
+{
+ char *to = buf;
+
+ /* copy the arg name */
+ if (to + len >= end)
+ return -E2BIG;
+ memcpy(to, arg, len);
+ to += len;
+
+ if (new_val == BOOTFLOWCL_EMPTY) {
+ /* no value */
+ } else {
+ bool need_quote = strchr(new_val, ' ');
+ len = strlen(new_val);
+
+ /* need space for value, equals sign and maybe two quotes */
+ if (to + 1 + 2 * need_quote + len >= end)
+ return -E2BIG;
+ *to++ = '=';
+ if (need_quote)
+ *to++ = '"';
+ memcpy(to, new_val, len);
+ to += len;
+ if (need_quote)
+ *to++ = '"';
+ }
+
+ return to - buf;
+}
+
+int cmdline_set_arg(char *buf, int maxlen, const char *cmdline,
+ const char *set_arg, const char *new_val, int *posp)
+{
+ bool found_arg = false;
+ const char *from;
+ char *to, *end;
+ int set_arg_len;
+ char empty = '\0';
+ int ret;
+
+ from = cmdline ?:
+
+ /* check if the value has quotes inside */
+ if (new_val && new_val != BOOTFLOWCL_EMPTY && strchr(new_val, '"'))
+ return -EBADF;
+
+ set_arg_len = strlen(set_arg);
+ for (to = buf, end = buf + maxlen; *from;) {
+ const char *val, *arg_end, *val_end, *p;
+ bool in_quote;
+
+ if (to >= end)
+ return -E2BIG;
+ while (*from == ' ')
+ from++;
+ if (!*from)
+ break;
+
+ /* find the end of this arg */
+ val = NULL;
+ arg_end = NULL;
+ val_end = NULL;
+ in_quote = false;
+ for (p = from;; p++) {
+ if (in_quote) {
+ if (!*p)
+ return -EINVAL;
+ if (*p == '"')
+ in_quote = false;
+ continue;
+ }
+ if (*p == '=') {
+ arg_end = p;
+ val = p + 1;
+ } else if (*p == '"') {
+ in_quote = true;
+ } else if (!*p || *p == ' ') {
+ val_end = p;
+ if (!arg_end)
+ arg_end = p;
+ break;
+ }
+ }
+ /*
+* At this point val_end points to the end of the value, or the
+* last char after the arg name, if there is no label.
+* arg_end is the char after the arg name
+* val points to the value, or NULL if there is none
+* char after the value.
+*
+*fred=1234
+*^ ^^ ^
+* from || |
+* / \\
+*arg_end val val_end
+*/
+ log_debug("from %s arg_end %ld val %ld val_end %ld\n", from,
+ (long)(arg_end - from), (long)(val - from),
+ (long)(val_end - from));
+
+ if (to != buf) {
+ if (to >= end)
+ return -E2BIG;
+ *to++ = ' ';
+ }
+
+ /* if this is the target arg, update it */
+ if (!strncmp(from, set_arg, arg_end - from)) {
+ if (!buf) {
+ bool has_quote = val_end[-1] == '"';
+
+ /*
+* exclude any start/end quotes from
+
[PATCH 13/18] bootstd: Support automatically setting Linux parameters
Some Linux parameters can be set automatically by U-Boot, if it knows the
device being used. For example, since U-Boot knows the serial console
being used, it can add parameters for earlycon and console.
Add support for this.
Note that this is an experimental feature and we will see how useful it
turns out to be. It is very handy for ChromeOS, since otherwise it is very
difficult to manually determine the UART address or port number,
particularly in a script.
Provide an example of how this is used with ChromeOS.
Signed-off-by: Simon Glass
---
boot/bootflow.c| 33 +
cmd/bootflow.c | 5 ++-
doc/usage/cmd/bootflow.rst | 75 +-
include/bootflow.h | 12 ++
4 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index dbf93701cfb..745472a0b7a 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -842,3 +843,35 @@ int bootflow_cmdline_get_arg(struct bootflow *bflow, const
char *arg,
return ret;
}
+
+int bootflow_cmdline_auto(struct bootflow *bflow, const char *arg)
+{
+ struct serial_device_info info;
+ char buf[50];
+ int ret;
+
+ ret = serial_getinfo(gd->cur_serial_dev, );
+ if (ret)
+ return ret;
+
+ *buf = '\0';
+ if (!strcmp("earlycon", arg)) {
+ snprintf(buf, sizeof(buf),
+"uart8250,mmio32,%#lx,%dn8", info.addr,
+info.baudrate);
+ } else if (!strcmp("console", arg)) {
+ snprintf(buf, sizeof(buf),
+"ttyS0,%dn8", info.baudrate);
+ }
+
+ if (!*buf) {
+ printf("Unknown param '%s\n", arg);
+ return -ENOENT;
+ }
+
+ ret = bootflow_cmdline_set_arg(bflow, arg, buf, true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index dc54124621c..9d93b457408 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -476,6 +476,9 @@ static int do_bootflow_cmdline(struct cmd_tbl *cmdtp, int
flag, int argc,
else
printf("%.*s\n", ret, val);
break;
+ case 'a': /* auto */
+ ret = bootflow_cmdline_auto(bflow, arg);
+ break;
}
if (ret < 0) {
printf("Operation failed\n");
@@ -495,7 +498,7 @@ static char bootflow_help_text[] =
"bootflow info [-d] - show info on current bootflow (-d
dump bootflow)\n"
"bootflow boot - boot current bootflow (or first
available if none selected)\n"
"bootflow menu [-t] - show a menu of available bootflows\n"
- "bootflow cmdline [set|get|clear|delete] [] - update
cmdline";
+ "bootflow cmdline [set|get|clear|delete|auto] [] -
update cmdline";
#else
"scan - boot first available bootflow\n";
#endif
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index 0dbbb4a327c..d5f5ae79882 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -13,7 +13,7 @@ Synopis
bootflow select []
bootflow info [-d]
bootflow boot
-bootflow cmdline [set|get|clear|delete] []
+bootflow cmdline [set|get|clear|delete|auto] []
Description
---
@@ -218,6 +218,16 @@ To delete a parameter entirely, use::
bootflow cmdline delete
+Automatic parameters are available in a very few cases. You can use these to
+add parmeters where the value is known by U-Boot. For example::
+
+bootflow cmdline auto earlycon
+bootflow cmdline auto console
+
+can be used to set the early console (or console) to a suitable value so that
+output appears on the serial port. This is only supported by the 16550 serial
+driver so far.
+
Example
---
@@ -450,6 +460,69 @@ Here is am example using the -e flag to see all errors::
(21 bootflows, 2 valid)
U-Boot>
+Here is an example of booting ChromeOS, adjusting the console beforehand. Note
that
+the cmdline is word-wrapped here and some parts of the command line are
elided::
+
+=> bootfl list
+Showing all bootflows
+Seq Method State UclassPart Name
Filename
+--- --- --
+0 cros ready nvme 0 5.10.153-20434-g98da1eb2c
+1 efi ready nvme c nvme#0.blk#1.bootdev.part
efi/boot/bootia32.efi
+2 efi ready usb_mass_2 usb_mass_storage.lun0.boo
efi/boot/bootia32.efi
+--- --- --
+(3 bootflows, 3 valid)
+=> bootfl sel 0
+=> bootfl inf
+Name: 5.10.153-20434-g98da1eb2cf9d
Please pull u-boot-dm
Hi Tom, https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/16143 The following changes since commit c9c2c95d4cd27fe0cd41fe13a863899d268f973c: Merge branch '2023-04-27-introduce-nvm-xip-block-storage-emulation' (2023-04-27 19:22:38 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-28apr23 for you to fetch changes up to f43fc16812487289e98389f0f643d20c444f9c9c: fdt: Indicate that people should use the ofnode API (2023-04-28 11:52:38 -0600) sandbox and fdt bug fixes / tweaks various other minor fixes Andrew Davis (1): binman: Use unsigned long over typedef ulong Bin Meng (2): boot: vbe_simple: Fix vbe_simple_read_bootflow() dependency dm: core: Make aliases_lookup static Heinrich Schuchardt (9): sandbox: fix fall through in sandbox_flash_bulk() sandbox: fix sandbox_hub_submit_control_msg() sandbox: spi: sandbox_sf_process_cmd() missing fallthrough sandbox: mark sandbox_exit() as no return. common: static fdt_simplefb_enable_existing_node() MAINTAINERS: assign include/os.h sandbox: fix return type of os_filesize() sandbox: correct posix_types.h define patman: fix class TestFunctional Hugo Villeneuve (1): fdt_support: fix comments syntax error Jan Kiszka (1): tools: Fall back to importlib_resources on Python 3.6 Johan Jonker (1): core: fdtaddr: use map_sysmem() as cast for the return Jorge Ramirez-Ortiz (1): drivers: tee: sandbox: Fix SCP03 control emulator Marek Vasut (1): test: fdt: Fix copyright message Pavel Skripkin (1): sandbox: disable tracing before unmapping RAM Rasmus Villemoes (2): uclass: add uclass_find_device_by_phandle_id() helper dm: core: introduce uclass_get_device_by_of_path() Simon Glass (2): binman: Use expanduser instead of HOME fdt: Indicate that people should use the ofnode API Tom Rini (1): bootflow: Rework do_bootflow_menu() slightly MAINTAINERS | 1 + arch/sandbox/cpu/cpu.c | 2 +- arch/sandbox/cpu/os.c | 8 ++-- arch/sandbox/cpu/state.c| 5 + arch/sandbox/include/asm/posix_types.h | 7 --- arch/sandbox/include/asm/u-boot-sandbox.h | 2 +- boot/vbe_simple.c | 12 +++- cmd/bootflow.c | 24 common/fdt_simplefb.c | 8 +++- common/fdt_support.c| 4 ++-- drivers/block/host_dev.c| 3 ++- drivers/core/fdtaddr.c | 6 +- drivers/core/of_access.c| 2 +- drivers/core/uclass.c | 50 +- drivers/mtd/spi/sandbox.c | 1 + drivers/sysreset/sysreset_sandbox.c | 1 - drivers/tee/sandbox.c | 15 +++ drivers/usb/emul/sandbox_flash.c| 1 + drivers/usb/emul/sandbox_hub.c | 30 +- include/binman_sym.h| 8 include/dm/uclass.h | 17 + include/fdt_simplefb.h | 1 - include/os.h| 2 +- lib/fdtdec.c| 3 +++ test/cmd/fdt.c | 2 +- test/dm/test-fdt.c | 5 - tools/binman/cmdline.py | 2 +- tools/binman/control.py | 6 +- tools/binman/test/blob_syms.c | 2 -- tools/binman/test/u_boot_binman_syms.c | 2 -- tools/binman/test/u_boot_binman_syms_size.c | 2 -- tools/buildman/control.py | 6 +- tools/patman/__main__.py| 6 +- tools/patman/func_test.py | 4 ++-- 34 files changed, 149 insertions(+), 101 deletions(-)
Re: [PATCH] sandbox: disable tracing before unmapping RAM
Hi Pavel, On Fri, 28 Apr 2023 at 13:20, Simon Glass wrote: > > Hi Tom, > > Tom Rini says: > > Simon takes sandbox patches himself and I've assigned this to him in > > patchwork, thanks for submitting the patch. > > > > Ah, sorry for noise then. I am just unfamiliar with u-boot development > process. > > Thank you! Note, I had to add a check for tracing being enabled, to avoid build errors. Regards, SImon
Re: [PATCH] dm: core: introduce uclass_get_device_by_of_path()
Hi Rasmus, On Fri, 28 Apr 2023 at 13:20, Simon Glass wrote: > > Hi Rasmus, > > On Thu, 13 Apr 2023 at 09:17, Rasmus Villemoes > wrote: > > > > There's quite a few instances of board-specific code doing > > > > off = fdt_path_offset(gd->fdt_blob, ...); > > ... > > ret = uclass_get_device_by_of_offset(..., off, ); > > > > looking for an eeprom or a pmic via some alias. Such code can be > > simplified a little if we have a helper for directly getting a device > > via device tree path (including being given as an alias). > > > > Implement it in terms of ofnode rather than raw offsets so that this > > will work whether live tree is enabled or not. > > > > Signed-off-by: Rasmus Villemoes > > --- > > drivers/core/uclass.c | 6 ++ > > include/dm/uclass.h | 17 + > > 2 files changed, 23 insertions(+) > > Looks fine but please add a test to ofnode.c Did you send a patch with a test? If so I missed it. Also please check my tweak to this (OF_REAL) Regards, Simon
Re: [PATCH 1/1] doc: man-page for cp
Hi Heinrich, On Fri, 28 Apr 2023 at 01:41, Heinrich Schuchardt wrote: > > Add a man-page for the cp command. > > Signed-off-by: Heinrich Schuchardt > --- > doc/usage/cmd/cp.rst | 83 > doc/usage/index.rst | 1 + > 2 files changed, 84 insertions(+) > create mode 100644 doc/usage/cmd/cp.rst > > diff --git a/doc/usage/cmd/cp.rst b/doc/usage/cmd/cp.rst > new file mode 100644 > index 00..897c0bb7df > --- /dev/null > +++ b/doc/usage/cmd/cp.rst > @@ -0,0 +1,83 @@ > +.. SPDX-License-Identifier: GPL-2.0+: > + > +cp command > +== > + > +Synopsis > + > + > +:: > + > +mm source target count > +mm.b source target count > +mm.w source target count > +mm.l source target count > +mm.q source target count Is this the cp or the mm command? I think it is better to do: mm. or something like that, to avoid repetition > + > +Description > +--- > + > +The cp command is used to copy *count* words of memory from the *source* To me it is confusing to use the term 'words' here. A word typically means a machine word in a computer, e.g. 32- or 64-bits. How about just referring to 'transfer size' or 'access size'? > +address to the *target* address. If the *target* address points to NOR flash, > +the flash is programmed. > + > +The word size is defined by the suffix defaulting to 32 bits: > + > +== > +suffix word size > +== > +.b 8 bit words > +.w 16 bit words > +.l 32 bit words > +.q 64 bit words > + 32 bit words > +== > + > +source > +source address, hexadecimal > + > +target > +target address, hexadecimal > + > +count > +number of words to be copied, hexadecimal > + > +Examples > + > + > +The example device has a NOR flash where the lower part of the flash is > +protected. We first copy to RAM, then to unprotected flash. Last we try to > +write to protectd flash. > + > +:: > + > +=> mtd list > +List of MTD devices: > +* nor0 > + - device: flash@0 > + - parent: root_driver > + - driver: cfi_flash > + - path: /flash@0 > + - type: NOR flash > + - block size: 0x2 bytes > + - min I/O: 0x1 bytes > + - 0x-0x0200 : "nor0" > +=> cp.b 402 500 20 > +=> cp.b 402 1e0 2 > +Copy to Flash... done > +=> cp.b 402 0 2 > +Copy to Flash... Can't write to protected Flash sectors > +=> > + > +Configuration > +- > + > +The cp command is available if CONFIG_CMD_MEMORY=y. Support for 64 bit words > +(cp.q) depends on CONFIG_MEM_SUPPORT_64BIT_DATA=y. Copying to flash depends > on > +CONFIG_MTD_NOR_FLASH=y. > + > +Return value > + > + > +The return value $? is set to 0 (true) if the command was successfully, > +1 (false) otherwise. > diff --git a/doc/usage/index.rst b/doc/usage/index.rst > index cdf710919a..0fde130a54 100644 > --- a/doc/usage/index.rst > +++ b/doc/usage/index.rst > @@ -41,6 +41,7 @@ Shell commands > cmd/cmp > cmd/coninfo > cmd/conitrace > + cmd/cp > cmd/cyclic > cmd/dm > cmd/ebtupdate > -- > 2.39.2 > Regards, Simon
Re: [PATCH] sandbox: disable tracing before unmapping RAM
Hi Tom, Tom Rini says: > Simon takes sandbox patches himself and I've assigned this to him in > patchwork, thanks for submitting the patch. > Ah, sorry for noise then. I am just unfamiliar with u-boot development process. Thank you! With regards, Pavel Skripkin Applied to u-boot-dm, thanks!
Re: [PATCH] uclass: add uclass_find_device_by_phandle_id() helper
On Thu, 13 Apr 2023 at 09:16, Rasmus Villemoes wrote: > > The functions uclass_find_device_by_phandle() and > uclass_get_device_by_phandle_id() both loop over a given uclass > looking for a device with a given phandle. Factor that out to a common > helper. > > For now, there are no (known potential) users of the new helper > outside uclass.c, so make it static. > > Signed-off-by: Rasmus Villemoes > --- > drivers/core/uclass.c | 42 ++ > 1 file changed, 18 insertions(+), 24 deletions(-) > Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH] dm: core: introduce uclass_get_device_by_of_path()
Hi Rasmus, On Thu, 13 Apr 2023 at 09:17, Rasmus Villemoes wrote: > > There's quite a few instances of board-specific code doing > > off = fdt_path_offset(gd->fdt_blob, ...); > ... > ret = uclass_get_device_by_of_offset(..., off, ); > > looking for an eeprom or a pmic via some alias. Such code can be > simplified a little if we have a helper for directly getting a device > via device tree path (including being given as an alias). > > Implement it in terms of ofnode rather than raw offsets so that this > will work whether live tree is enabled or not. > > Signed-off-by: Rasmus Villemoes > --- > drivers/core/uclass.c | 6 ++ > include/dm/uclass.h | 17 + > 2 files changed, 23 insertions(+) Looks fine but please add a test to ofnode.c Regards, Simon Applied to u-boot-dm, thanks!
Re: [PATCH] binman: Use expanduser instead of HOME
There may not be a HOME environment variable, so use the os.expanduser() function instead. Signed-off-by: Simon Glass --- tools/binman/bintool.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH 1/1] patman: fix class TestFunctional
On Fri, 21 Apr 2023 at 06:07, Heinrich Schuchardt
wrote:
>
> Variable orig_dir cannot be used in the finally block if it has not be
> assigned outside of the try block.
>
> tools/patman/func_test.py:523:21:
> E0601: Using variable 'orig_dir' before assignment
> (used-before-assignment)
>
> tools/patman/func_test.py:691:21:
> E0601: Using variable 'orig_dir' before assignment
> (used-before-assignment)
>
> Fixes: fd70986a62af ("patman: Add a test that uses gitpython")
> Fixes: be051c0c7741 ("patman: Detect missing upstream in
> CountCommitsToBranch")
> Signed-off-by: Heinrich Schuchardt
> ---
> tools/patman/func_test.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Simon Glass
Applied to u-boot-dm, thanks!
Re: [PATCH] test: fdt: Fix copyright message
On Sat, 22 Apr 2023 at 07:00, Marek Vasut wrote: > > Drop the map_to_sysmem() copy paste error. No functional change. > > Signed-off-by: Marek Vasut > --- > Cc: Jason Liu > Cc: Michal Simek > Cc: Ovidiu Panait > Cc: Simon Glass > --- > test/cmd/fdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH] fdt_support: fix comments syntax error
On Mon, 24 Apr 2023 at 14:51, Hugo Villeneuve wrote: > > From: Hugo Villeneuve > > Fix comments syntax error in fdt_node_offset_by_compat_reg() > description: > compatiable -> compatible > > Signed-off-by: Hugo Villeneuve > --- > common/fdt_support.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH] tools: Fall back to importlib_resources on Python 3.6
On Sat, 22 Apr 2023 at 08:42, Jan Kiszka wrote: > > From: Jan Kiszka > > importlib.resources became part of 3.7 only. Allow using distros with > 3.6 and the importlib_resources backport. > > Signed-off-by: Jan Kiszka > --- > > Tested on OpenSUSE 15.4 with importlib_resources 1.1.0. > > tools/binman/control.py | 6 +- > tools/buildman/control.py | 6 +- > tools/patman/__main__.py | 6 +- > 3 files changed, 15 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH v9] core: fdtaddr: use map_sysmem() as cast for the return
On Sun, 23 Apr 2023 at 03:19, Johan Jonker wrote: > > For the devfdt_get_addr_index_ptr() and devfdt_get_addr_size_index_ptr() > function use map_sysmem() function as cast for the return for use in > sandbox. Also fix sandbox test. > > Signed-off-by: Johan Jonker > --- > > Apply after: > [PATCH v8 00/24] Fixes for Rockchip NFC driver part 1 > with replacement: > [PATCH v9] core: fdtaddr: add devfdt_get_addr_size_index_ptr function > > --- > > Changed V9: > New patch. > Split use of map_sysmem() from previous series. > --- > drivers/core/fdtaddr.c | 11 +-- > test/dm/test-fdt.c | 5 - > 2 files changed, 13 insertions(+), 3 deletions(-) > Reviewed-by: Simon Glass Thanks for digging into this. Applied to u-boot-dm, thanks!
[PATCH 18/18] x86: coral: Adjust various config options
Add NVME support.
Add ms so it is easier to search for tables in memory.
Expand the command-line and print buffers so that we can deal with the
very long ChromeOS command lines. (typically 700 characters).
Enable BOOTSTD_FULL to get the full set of standard-boot options.
Replace the existing manual script with 'bootflow scan', since it can
find and boot the OS.
Finally, expand the malloc() space so we can read large kernels into a
bootflow.
Signed-off-by: Simon Glass
---
configs/chromebook_coral_defconfig | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/configs/chromebook_coral_defconfig
b/configs/chromebook_coral_defconfig
index f5995f22004..fe61153b93d 100644
--- a/configs/chromebook_coral_defconfig
+++ b/configs/chromebook_coral_defconfig
@@ -1,5 +1,6 @@
CONFIG_X86=y
CONFIG_TEXT_BASE=0x111
+CONFIG_SYS_MALLOC_LEN=0x200
CONFIG_SYS_MALLOC_F_LEN=0x3d00
CONFIG_NR_DRAM_BANKS=8
CONFIG_MAX_CPUS=8
@@ -22,6 +23,7 @@ CONFIG_X86_OFFSET_U_BOOT=0xffd0
CONFIG_X86_OFFSET_SPL=0xffe8
CONFIG_INTEL_ACPIGEN=y
CONFIG_INTEL_GENERIC_WIFI=y
+CONFIG_BOOTSTD_FULL=y
CONFIG_SYS_MONITOR_BASE=0x0111
CONFIG_CHROMEOS=y
CONFIG_BOOTSTAGE=y
@@ -33,8 +35,10 @@ CONFIG_BOOTSTAGE_STASH=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS_SUBST=y
CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; read mmc 0:2 10 0
80; setexpr loader *001004f0; setexpr size *00100518; setexpr blocks $size /
200; read mmc 0:2 10 80 $blocks; setexpr setup $loader - 1000; setexpr
cmdline_ptr $loader - 2000; setexpr.s cmdline *$cmdline_ptr; setexpr cmdline
gsub %U ${uuid}; if part uuid mmc 0:2 uuid; then zboot start 10 0 0 0
$setup cmdline; zboot load; zboot setup; zboot dump; zboot go;fi"
+CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; bootflow scan -lb"
CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_LOG=y
+CONFIG_LOGF_FUNC=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_LAST_STAGE_INIT=y
CONFIG_BLOBLIST=y
@@ -52,9 +56,11 @@ CONFIG_SPL_POWER=y
CONFIG_TPL_SYS_MALLOC_SIMPLE=y
CONFIG_TPL_POWER=y
CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PBSIZE=532
+CONFIG_SYS_CBSIZE=1024
+CONFIG_SYS_PBSIZE=1024
CONFIG_CMD_CPU=y
CONFIG_CMD_PMC=y
+CONFIG_CMD_MEM_SEARCH=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
CONFIG_CMD_PART=y
--
2.40.1.495.gc816e09b53d-goog
[PATCH 09/18] bootstd: Work around missing partition 1
If there is no partition numbered 1, we decide that there are no
partitions at all. That may not be correct, since at least one Debian
installed has just a single partition numbered 2.
Continue searching up to partition 3, just in case.
Signed-off-by: Simon Glass
---
boot/bootdev-uclass.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 57d29446476..9660ff75676 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -154,8 +154,15 @@ int bootdev_find_in_blk(struct udevice *dev, struct
udevice *blk,
ret = -ESHUTDOWN;
else
bflow->state = BOOTFLOWST_MEDIA;
- if (ret)
+ if (ret) {
+ /* allow partition 1 to be missing */
+ if (iter->part == 1) {
+ iter->max_part = 3;
+ ret = -ENOENT;
+ }
+
return log_msg_ret("part", ret);
+ }
/*
* Currently we don't get the number of partitions, so just
--
2.40.1.495.gc816e09b53d-goog
[PATCH 17/18] x86: coreboot: Adjust various config options
Drop IDE since this is not widely used anymore. Add NVME since it is becoming more popular. Add ms so it is easier to search for tables in memory. Expand the command-line and print buffers so that we can deal with the very long ChromeOS command lines. (typically 700 characters). Enable BOOTSTD_FULL to get the full set up standard-boot options. Finally, expand the malloc() space so we can read large kernels into a bootflow. Signed-off-by: Simon Glass --- configs/coreboot_defconfig | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 4db72899169..e8a915a64f9 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -1,5 +1,6 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x111 +CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="coreboot" @@ -8,19 +9,21 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_LOG=y +CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_HUSH_PARSER=y -CONFIG_SYS_PBSIZE=532 -CONFIG_CMD_IDE=y +CONFIG_SYS_CBSIZE=1024 +CONFIG_SYS_PBSIZE=1024 +CONFIG_CMD_MEM_SEARCH=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_USB=y @@ -48,13 +51,9 @@ CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_ACPIGEN is not set -CONFIG_SYS_IDE_MAXDEVICE=4 -CONFIG_SYS_ATA_DATA_OFFSET=0 -CONFIG_SYS_ATA_REG_OFFSET=0 -CONFIG_SYS_ATA_ALT_OFFSET=0 -CONFIG_ATAPI=y -CONFIG_LBA48=y -CONFIG_SYS_64BIT_LBA=y +CONFIG_MISC=y +CONFIG_NVMEM=y +CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SOUND=y -- 2.40.1.495.gc816e09b53d-goog
[PATCH 15/18] x86: zimage: Export the function to obtain the cmdline
Allow reading the command line from a zimage, so that it can be recorded
in the bootflow.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/zimage.h | 10 ++
arch/x86/lib/zimage.c | 11 ---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 966d7224eb1..9ad74dc0b94 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -89,4 +89,14 @@ void zimage_dump(struct boot_params *base_ptr);
int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
ulong base, char *cmdline);
+/*
+ * zimage_get_kernel_version() - Get the version string from a kernel
+ *
+ * @params: boot_params pointer
+ * @kernel_base: base address of kernel
+ * Return: Kernel version as a NUL-terminated string
+ */
+const char *zimage_get_kernel_version(struct boot_params *params,
+ void *kernel_base);
+
#endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 540d4d888bc..062e3d3e315 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -181,7 +181,7 @@ static int setup_device_tree(struct setup_header *hdr,
const void *fdt_blob)
return 0;
}
-static const char *get_kernel_version(struct boot_params *params,
+const char *zimage_get_kernel_version(struct boot_params *params,
void *kernel_base)
{
struct setup_header *hdr = >hdr;
@@ -189,10 +189,14 @@ static const char *get_kernel_version(struct boot_params
*params,
const char *s, *end;
bootproto = get_boot_protocol(hdr, false);
+ log_debug("bootproto %x, hdr->setup_sects %x\n", bootproto,
+ hdr->setup_sects);
if (bootproto < 0x0200 || hdr->setup_sects < 15)
return NULL;
/* sanity-check the kernel version in case it is missing */
+ log_debug("hdr->kernel_version %x, str at %p\n", hdr->kernel_version,
+ kernel_base + hdr->kernel_version + 0x200);
for (s = kernel_base + hdr->kernel_version + 0x200, end = s + 0x100; *s;
s++) {
if (!isprint(*s))
@@ -239,7 +243,7 @@ struct boot_params *load_zimage(char *image, unsigned long
kernel_size,
log_debug("Using boot protocol version %x.%02x\n",
(bootproto & 0xff00) >> 8, bootproto & 0xff);
- version = get_kernel_version(params, image);
+ version = zimage_get_kernel_version(params, image);
if (version)
printf("Linux kernel version %s\n", version);
else
@@ -728,7 +732,8 @@ void zimage_dump(struct boot_params *base_ptr)
print_num("Real mode switch", hdr->realmode_swtch);
print_num("Start sys seg", hdr->start_sys_seg);
print_num("Kernel version", hdr->kernel_version);
- version = get_kernel_version(base_ptr, (void *)state.bzimage_addr);
+ version = zimage_get_kernel_version(base_ptr,
+ (void *)state.bzimage_addr);
if (version)
printf(" @%p: %s\n", version, version);
print_num("Type of loader", hdr->type_of_loader);
--
2.40.1.495.gc816e09b53d-goog
[PATCH 16/18] bootstd: Add a simple bootmeth for ChromiumOS
It is possible to boot x86-based ChromeOS machines by parsing a table and
locating the kernel and command line. Add a bootmeth for this.
Signed-off-by: Simon Glass
---
boot/Kconfig | 11 ++
boot/Makefile| 1 +
boot/bootmeth_cros.c | 212 +++
configs/tools-only_defconfig | 1 +
4 files changed, 225 insertions(+)
create mode 100644 boot/bootmeth_cros.c
diff --git a/boot/Kconfig b/boot/Kconfig
index d95a2a70266..1dadd42f15e 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -462,6 +462,17 @@ config BOOTMETH_GLOBAL
EFI bootmgr, since they take full control over which bootdevs are
selected to boot.
+config BOOTMETH_CROS
+ bool "Bootdev support for Chromium OS"
+ depends on X86 || SANDBOX
+ default y
+ help
+ Enables support for booting Chromium OS using bootdevs. This uses the
+ kernel A slot and obtains the kernel command line from the parameters
+ provided there.
+
+ Note that only x86 devices are supported at present.
+
config BOOTMETH_DISTRO
bool "Bootdev support for distro boot"
select PXE_UTILS
diff --git a/boot/Makefile b/boot/Makefile
index 88193a1b60e..998a7f9c684 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO) += bootmeth_distro.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO_PXE) += bootmeth_pxe.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_CROS) += bootmeth_cros.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o
ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
new file mode 100644
index 000..440737060fd
--- /dev/null
+++ b/boot/bootmeth_cros.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootmethod for ChromiumOS
+ *
+ * Copyright 2023 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef CONFIG_X86
+#include
+#endif
+#include
+
+enum {
+ /* Offsets in the kernel-partition header */
+ KERN_START = 0x4f0,
+ KERN_SIZE = 0x518,
+
+ SETUP_OFFSET= 0x1000, /* bytes before base */
+ CMDLINE_OFFSET = 0x2000, /* bytes before base */
+ OFFSET_BASE = 0x10, /* assumed kernel load-address */
+};
+
+static int cros_check(struct udevice *dev, struct bootflow_iter *iter)
+{
+ /* This only works on block and network devices */
+ if (bootflow_iter_check_blk(iter))
+ return log_msg_ret("blk", -ENOTSUPP);
+
+ return 0;
+}
+
+static int copy_cmdline(const char *from, const char *uuid, char **bufp)
+{
+ const int maxlen = 2048;
+ char buf[maxlen];
+ char *cmd, *to, *end;
+ int len;
+
+ /* Allow space for cmdline + UUID */
+ len = strnlen(from, sizeof(buf));
+ if (len >= maxlen)
+ return -E2BIG;
+
+ log_debug("uuid %d %s\n", uuid ? (int)strlen(uuid) : 0, uuid);
+ for (to = buf, end = buf + maxlen - UUID_STR_LEN - 1; *from; from++) {
+ if (to >= end)
+ return -E2BIG;
+ if (from[0] == '%' && from[1] == 'U' && uuid &&
+ strlen(uuid) == UUID_STR_LEN) {
+ strcpy(to, uuid);
+ to += UUID_STR_LEN;
+ from++;
+ } else {
+ *to++ = *from;
+ }
+ }
+ *to = '\0';
+ len = to - buf;
+ cmd = strdup(buf);
+ if (!cmd)
+ return -ENOMEM;
+ free(*bufp);
+ *bufp = cmd;
+
+ return 0;
+}
+
+static int cros_read_bootflow(struct udevice *dev, struct bootflow *bflow)
+{
+ struct blk_desc *desc = dev_get_uclass_plat(bflow->blk);
+ ulong base, start, size, setup, cmdline, num_blks, kern_base;
+ struct disk_partition info;
+ const char *uuid = NULL;
+ void *buf, *hdr;
+ int ret;
+
+ log_debug("starting, part=%d\n", bflow->part);
+
+ /* We consider the whole disk, not any one partition */
+ if (bflow->part)
+ return log_msg_ret("max", -ENOENT);
+
+ /* Check partition 2 */
+ ret = part_get_info(desc, 2, );
+ if (ret)
+ return log_msg_ret("part", ret);
+
+ /* Make a buffer for the header information */
+ num_blks = SZ_4K >> desc->log2blksz;
+ log_debug("Reading header, blk=%s, start=%lx, blocks=%lx\n",
+ bflow->blk->name, (ulong)info.start, num_blks);
+ hdr = memalign(SZ_1K, SZ_4K);
+ if (!hdr)
+ return log_msg_ret("hdr", -ENOMEM);
+ ret = blk_read(bflow->blk,
[PATCH 14/18] x86: Add a function to boot a zimage
Add a direct interface to booting a zimage, so that bootstd can call it
without going through the command-line interface.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/zimage.h | 17
arch/x86/lib/zimage.c | 82 ++-
2 files changed, 88 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 000b38ea899..966d7224eb1 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -72,4 +72,21 @@ int setup_zimage(struct boot_params *setup_base, char
*cmd_line, int auto_boot,
*/
void zimage_dump(struct boot_params *base_ptr);
+/**
+ * zboot_start() - Boot a zimage
+ *
+ * Boot a zimage, given the component parts
+ *
+ * @addr: Address where the bzImage is moved before booting, either
+ * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR
+ * @base: Pointer to the boot parameters, typically at address
+ * DEFAULT_SETUP_BASE
+ * @initrd: Address of the initial ramdisk, or 0 if none
+ * @initrd_size: Size of the initial ramdisk, or 0 if none
+ * @cmdline: Command line to use for booting
+ * Return: -EFAULT on error (normally it does not return)
+ */
+int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+ ulong base, char *cmdline);
+
#endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index e5ea5129c1e..540d4d888bc 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -442,8 +443,7 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
-char *const argv[])
+static int zboot_load(void)
{
struct boot_params *base_ptr;
@@ -460,31 +460,51 @@ static int do_zboot_load(struct cmd_tbl *cmdtp, int flag,
int argc,
_address);
if (!base_ptr) {
puts("## Kernel loading failed ...\n");
- return CMD_RET_FAILURE;
+ return -EINVAL;
}
}
state.base_ptr = base_ptr;
- if (env_set_hex("zbootbase", (ulong)base_ptr) ||
+
+ return 0;
+}
+
+static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+ if (zboot_load())
+ return CMD_RET_FAILURE;
+
+ if (env_set_hex("zbootbase", map_to_sysmem(state.base_ptr)) ||
env_set_hex("zbootaddr", state.load_address))
return CMD_RET_FAILURE;
return 0;
}
+static int zboot_setup(void)
+{
+ struct boot_params *base_ptr = state.base_ptr;
+ int ret;
+
+ ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
+ 0, state.initrd_addr, state.initrd_size,
+ (ulong)state.cmdline);
+ if (ret)
+ return -EINVAL;
+
+ return 0;
+}
+
static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
struct boot_params *base_ptr = state.base_ptr;
- int ret;
if (!base_ptr) {
printf("base is not set: use 'zboot load' first\n");
return CMD_RET_FAILURE;
}
- ret = setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
- 0, state.initrd_addr, state.initrd_size,
- (ulong)state.cmdline);
- if (ret) {
+ if (zboot_setup()) {
puts("Setting up boot parameters failed ...\n");
return CMD_RET_FAILURE;
}
@@ -501,8 +521,7 @@ static int do_zboot_info(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
+static int zboot_go(void)
{
struct boot_params *params = state.base_ptr;
struct setup_header *hdr = >hdr;
@@ -522,11 +541,52 @@ static int do_zboot_go(struct cmd_tbl *cmdtp, int flag,
int argc,
/* we assume that the kernel is in place */
ret = boot_linux_kernel((ulong)state.base_ptr, entry, image_64bit);
+
+ return ret;
+}
+
+static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ int ret;
+
+ ret = zboot_go();
printf("Kernel returned! (err=%d)\n", ret);
return CMD_RET_FAILURE;
}
+int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+ ulong base, char *cmdline)
+{
+ int ret;
+
+ memset(, '\0', sizeof(state));
+
+ if (base) {
+ state.base_ptr = map_sysmem(base, 0);
+ state.load_address = addr;
+ } else {
+ state.bzimage_addr = addr;
+ }
+
[PATCH 10/18] bdinfo: Show information about the serial port
It is useful to see the detailed setting of the serial port, e.g. to
allow setting up earlycon or console for Linux. Add this output to the
'bdinfo' command.
Signed-off-by: Simon Glass
---
cmd/bdinfo.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index f709904c516..af68c06696a 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -103,6 +104,25 @@ static void show_video_info(void)
}
}
+static void print_serial(struct udevice *dev)
+{
+ struct serial_device_info info;
+ int ret;
+
+ if (!dev || !IS_ENABLED(CONFIG_DM_SERIAL))
+ return;
+
+ ret = serial_getinfo(dev, );
+ if (ret)
+ return;
+
+ bdinfo_print_num_l("serial addr", info.addr);
+ bdinfo_print_num_l(" width", info.reg_width);
+ bdinfo_print_num_l(" shift", info.reg_shift);
+ bdinfo_print_num_l(" offset", info.reg_offset);
+ bdinfo_print_num_l(" clock", info.clock);
+}
+
int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct bd_info *bd = gd->bd;
@@ -144,6 +164,7 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
if (IS_ENABLED(CONFIG_OF_REAL))
printf("devicetree = %s\n", fdtdec_get_srcname());
}
+ print_serial(gd->cur_serial_dev);
arch_print_bdinfo();
--
2.40.1.495.gc816e09b53d-goog
[PATCH 04/18] bootstd: Use bootdev instead of bootdevice
It seems better to call this a 'bootdev' since this is name used in the
documentation. The older 'Bootdevice' name is no-longer used and may cause
confusion with the 'bootdevice' environment variable.
Update throughout to use bootdev.
Signed-off-by: Simon Glass
---
boot/bootflow.c| 4 ++--
drivers/mmc/mmc_bootdev.c | 2 +-
drivers/scsi/scsi_bootdev.c| 2 +-
drivers/usb/host/usb_bootdev.c | 2 +-
include/bootdev.h | 2 +-
include/bootflow.h | 2 +-
net/eth_bootdev.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 8f2cb876bb4..487552fa28c 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -315,14 +315,14 @@ static int bootflow_check(struct bootflow_iter *iter,
struct bootflow *bflow)
/* If we got a valid bootflow, return it */
if (!ret) {
- log_debug("Bootdevice '%s' part %d method '%s': Found
bootflow\n",
+ log_debug("Bootdev '%s' part %d method '%s': Found bootflow\n",
dev->name, iter->part, iter->method->name);
return 0;
}
/* Unless there is nothing more to try, move to the next device */
else if (ret != BF_NO_MORE_PARTS && ret != -ENOSYS) {
- log_debug("Bootdevice '%s' part %d method '%s': Error %d\n",
+ log_debug("Bootdev '%s' part %d method '%s': Error %d\n",
dev->name, iter->part, iter->method->name, ret);
/*
* For 'all' we return all bootflows, even
diff --git a/drivers/mmc/mmc_bootdev.c b/drivers/mmc/mmc_bootdev.c
index b57b8a62276..55ecead2ddf 100644
--- a/drivers/mmc/mmc_bootdev.c
+++ b/drivers/mmc/mmc_bootdev.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Bootdevice for MMC
+ * Bootdev for MMC
*
* Copyright 2021 Google LLC
* Written by Simon Glass
diff --git a/drivers/scsi/scsi_bootdev.c b/drivers/scsi/scsi_bootdev.c
index 991013fe1ef..218221fa306 100644
--- a/drivers/scsi/scsi_bootdev.c
+++ b/drivers/scsi/scsi_bootdev.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Bootdevice for USB
+ * Bootdev for SCSI
*
* Copyright 2021 Google LLC
* Written by Simon Glass
diff --git a/drivers/usb/host/usb_bootdev.c b/drivers/usb/host/usb_bootdev.c
index 32919f99286..95df99a6e5c 100644
--- a/drivers/usb/host/usb_bootdev.c
+++ b/drivers/usb/host/usb_bootdev.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Bootdevice for USB
+ * Bootdev for USB
*
* Copyright 2021 Google LLC
* Written by Simon Glass
diff --git a/include/bootdev.h b/include/bootdev.h
index e72ef3650f7..1533adfe506 100644
--- a/include/bootdev.h
+++ b/include/bootdev.h
@@ -200,7 +200,7 @@ void bootdev_clear_bootflows(struct udevice *dev);
* All fields in @bflow must be set up. Note that @bflow->dev is used to add
the
* bootflow to that device.
*
- * @dev: Bootdevice device to add to
+ * @dev: Bootdev device to add to
* @bflow: Bootflow to add. Note that fields within bflow must be allocated
* since this function takes over ownership of these. This functions makes
* a copy of @bflow itself (without allocating its fields again), so the
diff --git a/include/bootflow.h b/include/bootflow.h
index f20f575030f..018d021b810 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -58,7 +58,7 @@ enum bootflow_flags_t {
*
* @bm_node: Points to siblings in the same bootdev
* @glob_node: Points to siblings in the global list (all bootdev)
- * @dev: Bootdevice device which produced this bootflow
+ * @dev: Bootdev device which produced this bootflow
* @blk: Block device which contains this bootflow, NULL if this is a network
* device or sandbox 'host' device
* @part: Partition number (0 for whole device)
diff --git a/net/eth_bootdev.c b/net/eth_bootdev.c
index 13e5fcd3bdf..0896d4e8175 100644
--- a/net/eth_bootdev.c
+++ b/net/eth_bootdev.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Bootdevice for ethernet (uses PXE)
+ * Bootdev for ethernet (uses PXE)
*
* Copyright 2021 Google LLC
* Written by Simon Glass
--
2.40.1.495.gc816e09b53d-goog
[PATCH 02/18] test: Skip flat-tree tests if devicetree is not used
Many tests don't actually use the devicetree at all so there is no point in running the tests both with livetree and flat tree. Check for this and skip the flat tree test in that case. Signed-off-by: Simon Glass --- test/test-main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/test/test-main.c b/test/test-main.c index b3c30d92937..f770bdb81ea 100644 --- a/test/test-main.c +++ b/test/test-main.c @@ -476,7 +476,8 @@ static int ut_run_test_live_flat(struct unit_test_state *uts, * (for sandbox we handle this by copying the tree, but not for other *boards) */ - if (!(test->flags & UT_TESTF_LIVE_TREE) && + if ((test->flags & UT_TESTF_SCAN_FDT) && + !(test->flags & UT_TESTF_LIVE_TREE) && (CONFIG_IS_ENABLED(OFNODE_MULTI_TREE) || !(test->flags & UT_TESTF_OTHER_FDT)) && (!runs || ut_test_run_on_flattree(test)) && -- 2.40.1.495.gc816e09b53d-goog
[PATCH 08/18] bootstd: Allow storing x86 setup information
On x86 boards Linux uses a block of binary data to provide information
about the command line, memory map, etc. Provide a way to store this in
the bootflow so it can be passed on to the OS.
Signed-off-by: Simon Glass
---
cmd/bootflow.c | 2 ++
include/bootflow.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index b20d5893632..155c71f83c2 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -336,6 +336,8 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int
flag, int argc,
else
puts("(none)");
putc('\n');
+ if (bflow->x86_setup)
+ printf("X86 setup: %p\n", bflow->x86_setup);
printf("Logo: %s\n", bflow->logo ?
simple_xtoa((ulong)map_to_sysmem(bflow->logo)) : "(none)");
if (bflow->logo) {
diff --git a/include/bootflow.h b/include/bootflow.h
index e49f3a24864..9baa8672083 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -82,6 +82,7 @@ enum bootflow_flags_t {
* @fdt_addr: Address of loaded fdt
* @flags: Flags for the bootflow (see enum bootflow_flags_t)
* @cmdline: OS command line, or NULL it not known (allocated)
+ * @x86_setup: Pointer to x86 setup block inside @buf, NULL if not present
*/
struct bootflow {
struct list_head bm_node;
@@ -106,6 +107,7 @@ struct bootflow {
ulong fdt_addr;
int flags;
char *cmdline;
+ char *x86_setup;
};
/**
--
2.40.1.495.gc816e09b53d-goog
[PATCH 06/18] bootstd: Allow storing the OS command line in the bootflow
Some operating systems have a command line which can be adjusted before
booting. Store this in the bootflow so it can be controlled within
U-Boot.
Fix up the example output while we are here, since there are a few new
items.
Signed-off-by: Simon Glass
---
cmd/bootflow.c | 6 ++
doc/usage/cmd/bootflow.rst | 5 -
include/bootflow.h | 2 ++
test/boot/bootflow.c | 1 +
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index aa06999e3db..59d1bdc25b7 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -324,6 +324,12 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int
flag, int argc,
printf("Buffer:%lx\n", (ulong)map_to_sysmem(bflow->buf));
printf("Size: %x (%d bytes)\n", bflow->size, bflow->size);
printf("OS:%s\n", bflow->os_name ? bflow->os_name : "(none)");
+ printf("Cmdline: ");
+ if (bflow->cmdline)
+ puts(bflow->cmdline);
+ else
+ puts("(none)");
+ putc('\n');
printf("Logo: %s\n", bflow->logo ?
simple_xtoa((ulong)map_to_sysmem(bflow->logo)) : "(none)");
if (bflow->logo) {
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index cad09bbec9a..1e14fd05ad5 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -258,7 +258,6 @@ displayed and booted::
Name: mmc@7e202000.bootdev.part_2
Device:mmc@7e202000.bootdev
Block dev: m...@7e202000.blk
-Sequence: 1
Method:distro
State: ready
Partition: 2
@@ -266,6 +265,10 @@ displayed and booted::
Filename: extlinux/extlinux.conf
Buffer:3db7ae88
Size: 232 (562 bytes)
+OS:Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl)
+Cmdline: (none)
+Logo: (none)
+FDT:
Error: 0
U-Boot> bootflow boot
** Booting bootflow 'smsc95xx_eth.bootdev.0'
diff --git a/include/bootflow.h b/include/bootflow.h
index 018d021b810..e49f3a24864 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -81,6 +81,7 @@ enum bootflow_flags_t {
* @fdt_size: Size of FDT file
* @fdt_addr: Address of loaded fdt
* @flags: Flags for the bootflow (see enum bootflow_flags_t)
+ * @cmdline: OS command line, or NULL it not known (allocated)
*/
struct bootflow {
struct list_head bm_node;
@@ -104,6 +105,7 @@ struct bootflow {
int fdt_size;
ulong fdt_addr;
int flags;
+ char *cmdline;
};
/**
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index fd0e1d62435..b9ac539107b 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -226,6 +226,7 @@ static int bootflow_cmd_info(struct unit_test_state *uts)
ut_assert_nextlinen("Buffer:");
ut_assert_nextline("Size: 253 (595 bytes)");
ut_assert_nextline("OS:Fedora-Workstation-armhfp-31-1.9
(5.3.7-301.fc31.armv7hl)");
+ ut_assert_nextline("Cmdline: (none)");
ut_assert_nextline("Logo: (none)");
ut_assert_nextline("FDT: ");
ut_assert_nextline("Error: 0");
--
2.40.1.495.gc816e09b53d-goog
[PATCH 05/18] bootstd: Correct baudrate typo
This is a copy error. Fix it. Signed-off-by: Simon Glass --- boot/bootmeth-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/bootmeth-uclass.c b/boot/bootmeth-uclass.c index 2aee1e0f0c5..139ab08c4ed 100644 --- a/boot/bootmeth-uclass.c +++ b/boot/bootmeth-uclass.c @@ -421,7 +421,7 @@ int bootmeth_common_read_file(struct udevice *dev, struct bootflow *bflow, /** * on_bootmeths() - Update the bootmeth order * - * This will check for a valid baudrate and only apply it if valid. + * This will check for a valid list of bootmeths and only apply it if valid. */ static int on_bootmeths(const char *name, const char *value, enum env_op op, int flags) -- 2.40.1.495.gc816e09b53d-goog
[PATCH 03/18] bootstd: Correct the name of the QEMU bootmeth
This does not relate to sandbox. Correct the name.
Signed-off-by: Simon Glass
---
boot/bootmeth_qfw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/bootmeth_qfw.c b/boot/bootmeth_qfw.c
index a5f95d4d0c5..0af745f 100644
--- a/boot/bootmeth_qfw.c
+++ b/boot/bootmeth_qfw.c
@@ -76,7 +76,7 @@ static int qfw_bootmeth_bind(struct udevice *dev)
{
struct bootmeth_uc_plat *plat = dev_get_uclass_plat(dev);
- plat->desc = "Sandbox boot for testing";
+ plat->desc = "QEMU boot using firmware interface";
return 0;
}
--
2.40.1.495.gc816e09b53d-goog
[PATCH 01/18] test: Restore test behaviour on failure
A recent change makes test continue to run after failure. This results in
a lot of useless output and may lead to a segfault. Fix this by adding
back the 'return' statement.
Fixes: fa847bb409d ("test: Wrap assert macros in ({ ... }) and fix")
Signed-off-by: Simon Glass
---
include/test/ut.h | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/include/test/ut.h b/include/test/ut.h
index dddf9ad241f..ea6ee95d734 100644
--- a/include/test/ut.h
+++ b/include/test/ut.h
@@ -130,7 +130,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
\
if (!(cond)) { \
ut_fail(uts, __FILE__, __LINE__, __func__, #cond); \
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -142,7 +142,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
if (!(cond)) { \
ut_failf(uts, __FILE__, __LINE__, __func__, #cond, \
fmt, ##args); \
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -157,7 +157,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
#expr1 " == " #expr2, \
"Expected %#x (%d), got %#x (%d)", \
_val1, _val1, _val2, _val2); \
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -175,7 +175,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
(unsigned long long)_val1, \
(unsigned long long)_val2, \
(unsigned long long)_val2);\
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -189,7 +189,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
ut_failf(uts, __FILE__, __LINE__, __func__, \
#expr1 " = " #expr2, \
"Expected \"%s\", got \"%s\"", _val1, _val2); \
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -208,7 +208,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
#expr1 " = " #expr2, \
"Expected \"%.*s\", got \"%.*s\"", \
_len, _val1, _len, _val2); \
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -228,7 +228,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
#expr1 " = " #expr2, \
"Expected \"%s\", got \"%s\"", \
__buf1, __buf2); \
- __ret = CMD_RET_FAILURE;\
+ return CMD_RET_FAILURE; \
} \
__ret; \
})
@@ -242,7 +242,7 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
ut_failf(uts, __FILE__, __LINE__, __func__,
[PATCH 00/18] bootstd: Add a bootmeth for ChromiumOS on x86
This series adds a simple bootmeth for ChromiumOS on x86. It uses zimage to boot the kernel. Full verified boot is not included at this stage - that is still a separate chunk of code to be brought into standard boot at some point. For now it just obtains the kernel and command line and boots. This should be enough to boot Chrome OS from coreboot on all x86 machines in circulation, although only Brya (2022) and Coral (2017) have been tested. ChromiumOS needs quite large kernel parameters, to hold the DM verity settings and other pieces. This makes it painful to modify just one parameter, since the whole cmdline must be adjusted at once. To cope with this, a new cmdline-editing feature is provided: the 'bootflow cmdline' command allows individual parameters to be added, modified and deleted. To deal with enabling debug console, a variant supports setting 'earlycon' and 'console' automatically. The 'bdinfo' command is updated to show serial-port info also. Booting the zimage is now done programmatically, rather than running through the command-line interface. Minor tweaks are made to the coreboot and coral config so that booting works correctly. Note that the ACPI tables are not updated with the required firmware information in this series, so a warning is shown on boot. This will be addressed later since it requires quite a bit of configuration. Finally, this fixes a recently introduced bug in unit testing and updates the algorithm to avoid running flat-tree tests which don't actually use the devicetree. Simon Glass (18): test: Restore test behaviour on failure test: Skip flat-tree tests if devicetree is not used bootstd: Correct the name of the QEMU bootmeth bootstd: Use bootdev instead of bootdevice bootstd: Correct baudrate typo bootstd: Allow storing the OS command line in the bootflow bootstd: Use the bootargs env var for changing the cmdline bootstd: Allow storing x86 setup information bootstd: Work around missing partition 1 bdinfo: Show information about the serial port bootstd: Add a function to update a command line bootstd: Add support for updating elements of the cmdline bootstd: Support automatically setting Linux parameters x86: Add a function to boot a zimage x86: zimage: Export the function to obtain the cmdline bootstd: Add a simple bootmeth for ChromiumOS x86: coreboot: Adjust various config options x86: coral: Adjust various config options arch/x86/include/asm/zimage.h | 27 +++ arch/x86/lib/zimage.c | 93 ++-- boot/Kconfig | 11 + boot/Makefile | 1 + boot/bootdev-uclass.c | 9 +- boot/bootflow.c| 327 - boot/bootmeth-uclass.c | 2 +- boot/bootmeth_cros.c | 212 +++ boot/bootmeth_qfw.c| 2 +- cmd/bdinfo.c | 21 ++ cmd/bootflow.c | 74 ++- configs/chromebook_coral_defconfig | 10 +- configs/coreboot_defconfig | 21 +- configs/tools-only_defconfig | 1 + doc/usage/cmd/bootflow.rst | 100 - drivers/mmc/mmc_bootdev.c | 2 +- drivers/scsi/scsi_bootdev.c| 2 +- drivers/usb/host/usb_bootdev.c | 2 +- include/bootdev.h | 2 +- include/bootflow.h | 100 - include/env_callback.h | 6 +- include/test/ut.h | 36 ++-- net/eth_bootdev.c | 2 +- test/boot/bootflow.c | 264 +++ test/test-main.c | 3 +- 25 files changed, 1268 insertions(+), 62 deletions(-) create mode 100644 boot/bootmeth_cros.c -- 2.40.1.495.gc816e09b53d-goog
Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi Jaehoon,
On Thu, Mar 23, 2023 at 02:18:39PM +0900, Jaehoon Chung wrote:
> Hi Andy,
>
> On 3/15/23 14:26, andy...@sony.com wrote:
> > Hi Jaehoon
> >
> >> commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
> >> Author: yuezhang...@sony.com
> >> Date: Wed Mar 17 06:44:37 2021 +
> >>
> >> Revert "mmc: sdhci: set to INT_DATA_END when there are data"
> >>
> >> This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
> >>
> >> Revert the above commit.
> >>
> >> To Andy,
> >>
> >> Was there any problem without above commit?
> >
> > Without above revert commit, we found "sdhci_transfer_data: Transfer data
> > timeout" on db410c board with v2018.01.
>
> Thanks for sharing it. I had been trying to find db410c board.
> I found its board, so I will try to check with/without its patch.
>
> After checked, I will reply again ASAP.
Did you find an opportunity to experiment with the db410c board?
Do you think it could be possible to get this in, and revert it again
in the future if a better solution is found?
Best regards,
Henrik Grimler
> Best Regards,
> Jaehoon Chung
>
> >
> > Best Regards
> > Andy Wu
> >
> >> -Original Message-
> >> From: Jaehoon Chung
> >> Sent: Monday, March 13, 2023 9:03 PM
> >> To: Henrik Grimler ; Jaehoon Chung
> >>
> >> Cc: jo...@diskos.nl; peng@nxp.com; Wu, Andy ;
> >> s...@chromium.org; u-boot@lists.denx.de;
> >> ~postmarketos/upstream...@lists.sr.ht
> >> Subject: Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
> >> SDHCI_QUIRK_BROKEN_R1B"
> >>
> >> Hi,
> >>
> >> On 3/11/23 19:31, Henrik Grimler wrote:
> >>> Hi Jaehoon,
> >>>
> >>> On Fri, Feb 10, 2023 at 09:00:33AM +0900, Jaehoon Chung wrote:
> Hi,
>
> > -Original Message-
> > From: U-Boot On Behalf Of Henrik
> > Grimler
> > Sent: Thursday, February 9, 2023 4:04 AM
> > To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
> > s...@chromium.org; m.szyprow...@samsung.com; u-boot@lists.denx.de;
> > ~postmarketos/upstream...@lists.sr.ht
> > Cc: Henrik Grimler
> > Subject: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
> >> SDHCI_QUIRK_BROKEN_R1B"
> >
> > This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
> >
> > Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
> > there are data"") reverted the alternative fix that was added for
> > Exynos 4 devices, causing an error when trying to boot from an sdcard:
> >
> > <...>
> > Loading Environment from MMC... sdhci_send_command: Timeout
> >> for status update!
> > mmc fail to send stop cmd
> > <...>
>
> Thanks for sharing issue.
>
> I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
> Because it was verified that it was working fine without
> >> SDHCI_QUIKR_BROKEN_RIB.
> >>>
> >>> Just wondering if you have had an opportunity to test this on any of
> >>> your devices? You can find v2 here, though this patch had no changes:
> >>> INVALID URI REMOVED
> >>>
> >> 3-February/508928.html__;!!JmoZiZGBv3RvKRSx!5wpP-x5Y69S7MynP1sOmQI
> >> HaVG
> >>> N9_ZLl5dxDDenNWPHdwFnNPdAEvBrUt69tSpQ9o0Nv-LQ9Gie_aGgP$
> >>
> >> In my opinion,
> >>
> >> commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
> >> Author: yuezhang...@sony.com
> >> Date: Wed Mar 17 06:44:37 2021 +
> >>
> >> Revert "mmc: sdhci: set to INT_DATA_END when there are data"
> >>
> >> This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
> >>
> >> Revert the above commit.
> >>
> >> To Andy,
> >>
> >> Was there any problem without above commit?
> >>
> >>
> >> Best Regards,
> >> Jaehoon Chung
> >>
> >>
> >>>
> Best Regards,
> Jaehoon Chung
> >>>
> >>> Best regards,
> >>> Henrik Grimler
> >>>
> >
> > Re-add the quirk to allow booting from sdcards again.
> >
> > Signed-off-by: Henrik Grimler
> > ---
> > drivers/mmc/s5p_sdhci.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c index
> > dee84263c3fd..3b74feae68c7 100644
> > --- a/drivers/mmc/s5p_sdhci.c
> > +++ b/drivers/mmc/s5p_sdhci.c
> > @@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host
> >> *host)
> > host->name = S5P_NAME;
> >
> > host->quirks = SDHCI_QUIRK_NO_HISPD_BIT |
> >> SDHCI_QUIRK_BROKEN_VOLTAGE |
> > - SDHCI_QUIRK_32BIT_DMA_ADDR |
> > + SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR
> >> |
> > SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
> > host->max_clk = 5200;
> > host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 |
> >> MMC_VDD_165_195;
> > --
> > 2.30.2
>
>
[PATCH] usb: ehci-mx6: move phy setup before register access
For the CONFIG_PHY case, move the PHY setup before the register access. This avoids a hang when updating the imx8mm.dtsi which moves the USB OTG power-domains to the PHY. Signed-off-by: Tim Harvey Tested-by: Fabio Estevam --- drivers/usb/host/ehci-mx6.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c index 91633f013a55..fae20838c60a 100644 --- a/drivers/usb/host/ehci-mx6.c +++ b/drivers/usb/host/ehci-mx6.c @@ -703,6 +703,10 @@ static int ehci_usb_probe(struct udevice *dev) usb_internal_phy_clock_gate(priv->phy_addr, 1); usb_phy_enable(ehci, priv->phy_addr); #endif +#else + ret = generic_setup_phy(dev, >phy, 0); + if (ret) + goto err_regulator; #endif #if CONFIG_IS_ENABLED(DM_REGULATOR) @@ -725,12 +729,6 @@ static int ehci_usb_probe(struct udevice *dev) mdelay(10); -#if defined(CONFIG_PHY) - ret = generic_setup_phy(dev, >phy, 0); - if (ret) - goto err_regulator; -#endif - hccr = (struct ehci_hccr *)((uintptr_t)>caplength); hcor = (struct ehci_hcor *)((uintptr_t)hccr + HC_LENGTH(ehci_readl(&(hccr)->cr_capbase))); -- 2.25.1
Re: [PATCH v8] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2023-02-05, Vagrant Cascadian wrote: > On 2023-02-06, Patrick Wildt wrote: >> The MNT Reform 2 is a modular DIY laptop. In its initial version it >> is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been >> lifted from BoundaryDevices official U-Boot downstream project. >> >> Signed-off-by: Patrick Wildt > > Tested booting Debian with a 6.1.x linux kernel on a mnt/reform2 using > nvme rootfs and microsd /boot. Some oddities with video and wifi that do > not occur with the vendor u-boot, but seems like huge progress. The patch still applies to master; could this be considered for merging soon? live well, vagrant >> --- >> Changes since v7: >> - Re-added lost ramdisk_addr_r. >> Changes since v6: >> - Cleaned up some CONFIG_* pollution. >> Changes since v5: >> - Adjusted to further Binman changes. >> - Adjusted to further Kconfig conversions. >> - Removed some phy init in favor of DM. >> - Removed some pinmux which are now handled by DM_SERIAL. >> - Compared with Librem5/EVK and adjusted for similarity. >> Changes since v4: >> - Adjusted to Kconfig conversions. >> - Removed U-Boot-specific device tree changes. >> - Synced device tree to Linux v5.19-rc3. >> Changes since v3: >> - Adjusted to Binman changes in main branch. >> - Cleaned up environment variables akin to i.MX8MM. >> - Added vendor-prefix to device tree filename. >> - Provided ramdisk_addr_r. >> Changes since v2: >> - Switched to Binman. >> Changes since v1: >> - Synced DTS with files in Linux git repo. >> - Added support for USB host ports. >> >> arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + >> arch/arm/mach-imx/imx8m/Kconfig |7 + >> board/mntre/imx8mq_reform2/Kconfig| 15 + >> board/mntre/imx8mq_reform2/MAINTAINERS|7 + >> board/mntre/imx8mq_reform2/Makefile | 12 + >> board/mntre/imx8mq_reform2/imx8mq_reform2.c | 171 +++ >> board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 + >> .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ >> board/mntre/imx8mq_reform2/spl.c | 260 + >> configs/imx8mq_reform2_defconfig | 107 ++ >> include/configs/imx8mq_reform2.h | 67 ++ >> 11 files changed, 1766 insertions(+) >> create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi >> create mode 100644 board/mntre/imx8mq_reform2/Kconfig >> create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS >> create mode 100644 board/mntre/imx8mq_reform2/Makefile >> create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c >> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c >> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h >> create mode 100644 board/mntre/imx8mq_reform2/spl.c >> create mode 100644 configs/imx8mq_reform2_defconfig >> create mode 100644 include/configs/imx8mq_reform2.h signature.asc Description: PGP signature
[PATCH 1/1] pci: pcie_dw_rockchip: support fixed vcc3v3 regulator type
If the regulator is fixed, the call to regulator_set_value will fail with
-ENOSYS as fixed regulators do not support dm_regulator_ops->set_value.
see: regulator-uclass.c, regulator_set_value(), ops->set_value
This patch ignores -ENOSYS and enables the regulator via
regulator_set_enable which should be suitable for all regulator types.
Signed-off-by: John Clark
---
drivers/pci/pcie_dw_rockchip.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
index 9322e735b9..a30fb45222 100644
--- a/drivers/pci/pcie_dw_rockchip.c
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -289,6 +289,13 @@ static int rockchip_pcie_init_port(struct udevice *dev)
/* Set power and maybe external ref clk input */
if (priv->vpcie3v3) {
ret = regulator_set_value(priv->vpcie3v3, 330);
+ if (ret && ret != -ENOSYS) {
+ dev_err(priv->dw.dev,
+ "failed to set vpcie3v3 value (ret=%d)\n", ret);
+ return ret;
+ }
+
+ ret = regulator_set_enable(priv->vpcie3v3, true);
if (ret) {
dev_err(priv->dw.dev, "failed to enable vpcie3v3
(ret=%d)\n",
ret);
--
2.39.2 (Apple Git-143)
[PATCH 0/1] pci: pcie_dw_rockchip: support fixed vcc3v3 regulator type
When trying to nvme boot rk3568 boards (tested with odroid-m1 and nanopi-r5s), it failes with error -19. This is because it is trying to set the voltage of a fixed-regulator to 3.3v. John Clark (1): pci: pcie_dw_rockchip: support fixed vcc3v3 regulator type drivers/pci/pcie_dw_rockchip.c | 7 +++ 1 file changed, 7 insertions(+) -- 2.39.2 (Apple Git-143)
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
Hi Tim, On Fri, Apr 28, 2023 at 2:59 PM Tim Harvey wrote: > I believe the fix we need is the following which moves phy setup > before the register access (where it should have been along with the > case for !defined(CONFIG_PHY): ... > If everyone agrees here I'll submit a formal patch which should get > applied through Marek via the usb tree before the dt sync. This works for me, thanks. When you submit it, feel free to add: Tested-by: Fabio Estevam
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 9:44 AM Adam Ford wrote:
>
> On Fri, Apr 28, 2023 at 11:26 AM Fabio Estevam wrote:
> >
> > Hi Tim,
> >
> > On Fri, Apr 28, 2023 at 12:48 PM Tim Harvey wrote:
> >
> > > Yes I think that is similar enough to test. In my experience simply
> > > enabling otg2 via dt on imx8mm-evk shows the issue I see here but
> > > Fabio says he sees a hang on 'usb start' even before this dt sync and
> > > I don't know why my results on an imx8mm-evk differ.
> >
> > I started from scratch today and now our results match.
> >
> > Applied the following change against U-Boot master:
> >
> > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> > index 7d6317d95b13..898639e33d5e 100644
> > --- a/arch/arm/dts/imx8mm-evk.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk.dtsi
> > @@ -417,6 +417,10 @@
> > };
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > assigned-clocks = < IMX8MM_CLK_USDHC2>;
> > assigned-clock-rates = <2>;
> > diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> > index ab9ad41b4548..70c7a21f2d9f 100644
> > --- a/configs/imx8mm_evk_defconfig
> > +++ b/configs/imx8mm_evk_defconfig
> > @@ -119,3 +119,4 @@ CONFIG_CI_UDC=y
> > CONFIG_SDP_LOADADDR=0x4040
> > CONFIG_USB_GADGET_DOWNLOAD=y
> > CONFIG_IMX_WATCHDOG=y
> > +CONFIG_CMD_USB=y
> > --
> > 2.34.1
> >
> > Running "usb start" does not hang.
> >
> > Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" does not work (SD
> > card is not mounted on PC on the second time).
> >
> > After applying the imx8mm.dtsi sync with kernel 6.3:
> >
> > Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" works fine.
> >
> > "usb start" hangs.
> >
> > So, yes, I agree we cannot do the imx8mm.dtsi sync with 6.3 right now
> > as we need to fix the USB hang first.
> >
> > If anyone has any ideas as to why syncing the commit below:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v6.3=4585c79ff477f9517b7f384a4fce351417e8fa36
> >
> > causes issues in U-Boot, please let us know.
>
> I am not in a place to test this as I am traveling, but I thought I'd
> throw out an idea. The power-domain looks like it moved to the
> usbphynop2 driver which has the compatible name of "usb-nop-xceiv"
> Is there a a driver for this? Does it get enabled?
> If not, maybe we could update the imx8mm-u-u-boot.dtsi to restore the
> power-domains to a driver that is present.
>
Adam,
Ya, I think you were on the right track here.
There is a driver (driver/phy/nop-phy.c) which does get enabled but
with the dt sync the phy's power domain gets enabled after EHCI
registers are accessed.
I believe the fix we need is the following which moves phy setup
before the register access (where it should have been along with the
case for !defined(CONFIG_PHY):
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 91633f013a55..fae20838c60a 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -703,6 +703,10 @@ static int ehci_usb_probe(struct udevice *dev)
usb_internal_phy_clock_gate(priv->phy_addr, 1);
usb_phy_enable(ehci, priv->phy_addr);
#endif
+#else
+ ret = generic_setup_phy(dev, >phy, 0);
+ if (ret)
+ goto err_regulator;
#endif
#if CONFIG_IS_ENABLED(DM_REGULATOR)
@@ -725,12 +729,6 @@ static int ehci_usb_probe(struct udevice *dev)
mdelay(10);
-#if defined(CONFIG_PHY)
- ret = generic_setup_phy(dev, >phy, 0);
- if (ret)
- goto err_regulator;
-#endif
-
hccr = (struct ehci_hccr *)((uintptr_t)>caplength);
hcor = (struct ehci_hcor *)((uintptr_t)hccr +
HC_LENGTH(ehci_readl(&(hccr)->cr_capbase)));
If everyone agrees here I'll submit a formal patch which should get
applied through Marek via the usb tree before the dt sync.
Best Regards,
Tim
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 11:26 AM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Fri, Apr 28, 2023 at 12:48 PM Tim Harvey wrote:
>
> > Yes I think that is similar enough to test. In my experience simply
> > enabling otg2 via dt on imx8mm-evk shows the issue I see here but
> > Fabio says he sees a hang on 'usb start' even before this dt sync and
> > I don't know why my results on an imx8mm-evk differ.
>
> I started from scratch today and now our results match.
>
> Applied the following change against U-Boot master:
>
> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> index 7d6317d95b13..898639e33d5e 100644
> --- a/arch/arm/dts/imx8mm-evk.dtsi
> +++ b/arch/arm/dts/imx8mm-evk.dtsi
> @@ -417,6 +417,10 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> assigned-clocks = < IMX8MM_CLK_USDHC2>;
> assigned-clock-rates = <2>;
> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> index ab9ad41b4548..70c7a21f2d9f 100644
> --- a/configs/imx8mm_evk_defconfig
> +++ b/configs/imx8mm_evk_defconfig
> @@ -119,3 +119,4 @@ CONFIG_CI_UDC=y
> CONFIG_SDP_LOADADDR=0x4040
> CONFIG_USB_GADGET_DOWNLOAD=y
> CONFIG_IMX_WATCHDOG=y
> +CONFIG_CMD_USB=y
> --
> 2.34.1
>
> Running "usb start" does not hang.
>
> Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" does not work (SD
> card is not mounted on PC on the second time).
>
> After applying the imx8mm.dtsi sync with kernel 6.3:
>
> Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" works fine.
>
> "usb start" hangs.
>
> So, yes, I agree we cannot do the imx8mm.dtsi sync with 6.3 right now
> as we need to fix the USB hang first.
>
> If anyone has any ideas as to why syncing the commit below:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v6.3=4585c79ff477f9517b7f384a4fce351417e8fa36
>
> causes issues in U-Boot, please let us know.
I am not in a place to test this as I am traveling, but I thought I'd
throw out an idea. The power-domain looks like it moved to the
usbphynop2 driver which has the compatible name of "usb-nop-xceiv"
Is there a a driver for this? Does it get enabled?
If not, maybe we could update the imx8mm-u-u-boot.dtsi to restore the
power-domains to a driver that is present.
adam
>
> Thanks
Re: [PATCH v5 1/3] regulator: implement basic reference counter
Hi Eugen,
On Fri, 28 Apr 2023 at 01:39, Eugen Hristev wrote:
>
> On 4/28/23 02:39, Tim Harvey wrote:
> > On Wed, Apr 19, 2023 at 6:45 AM Eugen Hristev
> > wrote:
> >>
> >> Some devices share a regulator supply, when the first one will request
> >> regulator disable, the second device will have it's supply cut off before
> >> graciously shutting down. Hence there will be timeouts and other failed
> >> operations.
> >> Implement a reference counter mechanism similar with what is done in
> >> Linux, to keep track of enable and disable requests, and only disable the
> >> regulator when the last of the consumers has requested shutdown.
> >>
> >> Signed-off-by: Eugen Hristev
> >> Reviewed-by: Simon Glass
> >> ---
> >> Changes in v5:
> >> - none
> >> Changes in v4:
> >> - add documentation for error codes
> >> Changes in v3:
> >> - add error return codes
> >> Changes in v2:
> >> - add info in header regarding the function
> >>
> >> drivers/power/regulator/regulator_common.c | 22 ++
> >> drivers/power/regulator/regulator_common.h | 21 +
> >> 2 files changed, 43 insertions(+)
> >>
> >> diff --git a/drivers/power/regulator/regulator_common.c
> >> b/drivers/power/regulator/regulator_common.c
> >> index 93d8196b381e..484a4fc31ef7 100644
> >> --- a/drivers/power/regulator/regulator_common.c
> >> +++ b/drivers/power/regulator/regulator_common.c
> >> @@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice
> >> *dev,
> >> return 0;
> >> }
> >>
> >> + /* If previously enabled, increase count */
> >> + if (enable && dev_pdata->enable_count > 0) {
> >> + dev_pdata->enable_count++;
> >> + return -EALREADY;
> >> + }
> >> +
> >> + if (!enable) {
> >> + if (dev_pdata->enable_count > 1) {
> >> + /* If enabled multiple times, decrease count */
> >> + dev_pdata->enable_count--;
> >> + return -EBUSY;
> >> + } else if (!dev_pdata->enable_count) {
> >> + /* If already disabled, do nothing */
> >> + return -EALREADY;
> >> + }
> >> + }
> >> +
> >
> > Eugen,
> >
> > Thank you for working on this series!
>
> Hi Tim,
>
> Thank you for testing and having a look on my patches.
> >
> > I wonder if instead of returning a failure you should print an error
> > here but return 0 in order to not break unbalanced regulator calls
>
> Initially I did that, but Simon forced me to return error as you see now.
If you want to have a special function that consumes errors, you can
add one, e.g. that wraps the one that does report errors. My objection
is when something goes wrong and it is silently ignored, since it
tends to make problems build up, people add work-arounds, etc.
>
> > (like what is done in clk_disable()). I see that you have another
> > patch in this series which handles htis for
> > regulator_set_enable_if_allowed() but that doesn't cover drivers that
> > call regulator_common_set_enable() directly such as
> > drivers/power/regulator/fixed.c and
> > drivers/power/regulator/gpio-regulator.c.
>
> I believe Jonas (in CC) fixed those with a patch, but at the moment I am
> lost in providing you a link to it
> >
> > I know there is an unbalanced call currently on imx8mm that this patch
> > causes a failure where it previously did not:
> > u-boot=> usb start && usb tree
> > starting USB...
> > Bus usb@32e4: Bus usb@32e5: Error enabling VBUS supply (ret=-114)
> > probe failed, error -114
> >
>
> That's a good catch.
> I expected such things would happen if I would return error in those
> cases, so it might be that this is not the only case.
> If you are able to test that board, do you wish me to send you a patch
> that changes the code to using regulator_set_enable_if_allowed() ?
Regards,
Simon
Re: [PATCH v5 1/3] regulator: implement basic reference counter
On Fri, Apr 28, 2023 at 12:39 AM Eugen Hristev
wrote:
>
> On 4/28/23 02:39, Tim Harvey wrote:
> > On Wed, Apr 19, 2023 at 6:45 AM Eugen Hristev
> > wrote:
> >>
> >> Some devices share a regulator supply, when the first one will request
> >> regulator disable, the second device will have it's supply cut off before
> >> graciously shutting down. Hence there will be timeouts and other failed
> >> operations.
> >> Implement a reference counter mechanism similar with what is done in
> >> Linux, to keep track of enable and disable requests, and only disable the
> >> regulator when the last of the consumers has requested shutdown.
> >>
> >> Signed-off-by: Eugen Hristev
> >> Reviewed-by: Simon Glass
> >> ---
> >> Changes in v5:
> >> - none
> >> Changes in v4:
> >> - add documentation for error codes
> >> Changes in v3:
> >> - add error return codes
> >> Changes in v2:
> >> - add info in header regarding the function
> >>
> >> drivers/power/regulator/regulator_common.c | 22 ++
> >> drivers/power/regulator/regulator_common.h | 21 +
> >> 2 files changed, 43 insertions(+)
> >>
> >> diff --git a/drivers/power/regulator/regulator_common.c
> >> b/drivers/power/regulator/regulator_common.c
> >> index 93d8196b381e..484a4fc31ef7 100644
> >> --- a/drivers/power/regulator/regulator_common.c
> >> +++ b/drivers/power/regulator/regulator_common.c
> >> @@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice
> >> *dev,
> >> return 0;
> >> }
> >>
> >> + /* If previously enabled, increase count */
> >> + if (enable && dev_pdata->enable_count > 0) {
> >> + dev_pdata->enable_count++;
> >> + return -EALREADY;
> >> + }
> >> +
> >> + if (!enable) {
> >> + if (dev_pdata->enable_count > 1) {
> >> + /* If enabled multiple times, decrease count */
> >> + dev_pdata->enable_count--;
> >> + return -EBUSY;
> >> + } else if (!dev_pdata->enable_count) {
> >> + /* If already disabled, do nothing */
> >> + return -EALREADY;
> >> + }
> >> + }
> >> +
> >
> > Eugen,
> >
> > Thank you for working on this series!
>
> Hi Tim,
>
> Thank you for testing and having a look on my patches.
> >
> > I wonder if instead of returning a failure you should print an error
> > here but return 0 in order to not break unbalanced regulator calls
>
> Initially I did that, but Simon forced me to return error as you see now.
Ok, I see that discussion here:
https://patchwork.ozlabs.org/project/uboot/patch/20230328130127.20279-1-eugen.hris...@collabora.com/#3086660
>
> > (like what is done in clk_disable()). I see that you have another
> > patch in this series which handles htis for
> > regulator_set_enable_if_allowed() but that doesn't cover drivers that
> > call regulator_common_set_enable() directly such as
> > drivers/power/regulator/fixed.c and
> > drivers/power/regulator/gpio-regulator.c.
>
> I believe Jonas (in CC) fixed those with a patch, but at the moment I am
> lost in providing you a link to it
Are you thinking of "pci: pcie_dw_rockchip: Use
regulator_set_enable_if_allowed"
https://patchwork.ozlabs.org/project/uboot/patch/20230422181943.889436-3-jo...@kwiboo.se/
?
I added some debug prints to regulator_set_enable and see:
starting USB...
Bus usb@32e4: regulator_set_enable regulator-usb-otg1 enable
regulator_set_enable regulator-usb-otg1 enable ret=0
Bus usb@32e5: regulator_set_enable regulator-usb-otg2 enable
regulator_set_enable regulator-usb-otg2 enable ret=0
regulator_set_enable regulator-usb-otg2 enable
regulator_set_enable regulator-usb-otg2 enable ret=-114
Error enabling VBUS supply (ret=-114)
regulator_set_enable regulator-usb-otg2 disable
regulator_set_enable regulator-usb-otg2 disable ret=-16
probe failed, error -114
So clearly something is trying to enable regulator-usb-otg2 when it's
already enabled but I don't think that should be considered an error
and cause a failure.
Simon, is this what you were intending with your feedback?
> >
> > I know there is an unbalanced call currently on imx8mm that this patch
> > causes a failure where it previously did not:
> > u-boot=> usb start && usb tree
> > starting USB...
> > Bus usb@32e4: Bus usb@32e5: Error enabling VBUS supply (ret=-114)
> > probe failed, error -114
> >
>
> That's a good catch.
> I expected such things would happen if I would return error in those
> cases, so it might be that this is not the only case.
> If you are able to test that board, do you wish me to send you a patch
> that changes the code to using regulator_set_enable_if_allowed() ?
>
Yes, I can test. Are you thinking changing the calls to
regulator_common_set_enable (used in
drivers/power/regulator/fixed{gpio-regulator,regulator_common} to a
wrapper calling regulator_common_set_enable_if_allowed instead? I
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
Hi Tim,
On Fri, Apr 28, 2023 at 12:48 PM Tim Harvey wrote:
> Yes I think that is similar enough to test. In my experience simply
> enabling otg2 via dt on imx8mm-evk shows the issue I see here but
> Fabio says he sees a hang on 'usb start' even before this dt sync and
> I don't know why my results on an imx8mm-evk differ.
I started from scratch today and now our results match.
Applied the following change against U-Boot master:
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
index 7d6317d95b13..898639e33d5e 100644
--- a/arch/arm/dts/imx8mm-evk.dtsi
+++ b/arch/arm/dts/imx8mm-evk.dtsi
@@ -417,6 +417,10 @@
};
};
+ {
+ status = "okay";
+};
+
{
assigned-clocks = < IMX8MM_CLK_USDHC2>;
assigned-clock-rates = <2>;
diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
index ab9ad41b4548..70c7a21f2d9f 100644
--- a/configs/imx8mm_evk_defconfig
+++ b/configs/imx8mm_evk_defconfig
@@ -119,3 +119,4 @@ CONFIG_CI_UDC=y
CONFIG_SDP_LOADADDR=0x4040
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_IMX_WATCHDOG=y
+CONFIG_CMD_USB=y
--
2.34.1
Running "usb start" does not hang.
Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" does not work (SD
card is not mounted on PC on the second time).
After applying the imx8mm.dtsi sync with kernel 6.3:
Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" works fine.
"usb start" hangs.
So, yes, I agree we cannot do the imx8mm.dtsi sync with 6.3 right now
as we need to fix the USB hang first.
If anyone has any ideas as to why syncing the commit below:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v6.3=4585c79ff477f9517b7f384a4fce351417e8fa36
causes issues in U-Boot, please let us know.
Thanks
[PATCH] board: cssi: Migrate to hashed password
Use a hashed password instead of clear text in order to improve board security. Signed-off-by: Christophe Leroy --- Will be part of soon to come pull request configs/CMPC885_defconfig | 5 - configs/MCR3000_defconfig | 5 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/configs/CMPC885_defconfig b/configs/CMPC885_defconfig index 1fe67d02f2..b1df954bee 100644 --- a/configs/CMPC885_defconfig +++ b/configs/CMPC885_defconfig @@ -23,8 +23,11 @@ CONFIG_FIT=y CONFIG_OF_BOARD_SETUP=y CONFIG_BOOTDELAY=5 CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_FLUSH_STDIN=y CONFIG_AUTOBOOT_PROMPT="\nEnter password - autoboot in %d sec...\n" -CONFIG_AUTOBOOT_DELAY_STR="root" +CONFIG_AUTOBOOT_ENCRYPTION=y +CONFIG_AUTOBOOT_STOP_STR_ENABLE=y +CONFIG_AUTOBOOT_STOP_STR_SHA256="4813494d137e1631bba301d5acab6e7bb7aa74ce1185d456565ef51d737677b2" CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="run flashboot" CONFIG_BOARD_EARLY_INIT_R=y diff --git a/configs/MCR3000_defconfig b/configs/MCR3000_defconfig index fc2bf5b2f9..d113ffe899 100644 --- a/configs/MCR3000_defconfig +++ b/configs/MCR3000_defconfig @@ -24,8 +24,11 @@ CONFIG_OF_BOARD_SETUP=y CONFIG_SYS_MONITOR_BASE=0x0400 CONFIG_BOOTDELAY=5 CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_FLUSH_STDIN=y CONFIG_AUTOBOOT_PROMPT="\nEnter password - autoboot in %d sec...\n" -CONFIG_AUTOBOOT_DELAY_STR="root" +CONFIG_AUTOBOOT_ENCRYPTION=y +CONFIG_AUTOBOOT_STOP_STR_ENABLE=y +CONFIG_AUTOBOOT_STOP_STR_SHA256="4813494d137e1631bba301d5acab6e7bb7aa74ce1185d456565ef51d737677b2" CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="run flashboot" # CONFIG_HWCONFIG is not set -- 2.39.2
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 8:32 AM Adam Ford wrote:
>
> On Fri, Apr 28, 2023 at 10:27 AM Tim Harvey wrote:
> >
> > On Fri, Apr 28, 2023 at 4:57 AM Adam Ford wrote:
> > >
> > > On Thu, Apr 27, 2023 at 5:25 PM Tim Harvey wrote:
> > > >
> > > > On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam
> > > > wrote:
> > > > >
> > > > > On Thu, Apr 27, 2023 at 4:44 PM Tim Harvey
> > > > > wrote:
> > > > >
> > > > > > Fabio,
> > > > > >
> > > > > > Sorry for the confusion.
> > > > > >
> > > > > > This imx8mm dt sync patch will hang on imx8mm boards that use 'both'
> > > > > > usbotg1 and usbotg2. You can reproduce this hang on your imx8mm-evk
> > > > > > by
> > > > > > enabling usbotg2 in the dt (the board has it but it is not enabled
> > > > > > due
> > > > > > to the gpio based usb 3.0 mux not being sorted out yet):
> > > > > > + {
> > > > > > + dr_mode = "otg";
> > > > > > + status = "okay";
> > > > > > +};
> > > > > > +
> > > > > >
> > > > > > u-boot=> usb start && usb tree
> > > > > > starting USB...
> > > > > > Bus usb@32e4: Bus usb@32e5:
> > > > > > ^^^ imx8mm-evk hangs
> > > > >
> > > > > Yes, I can reproduce the hang, but it happens with or without the
> > > > > imx8mm dt sync.
> > > > >
> > > >
> > > > Fabio,
> > > >
> > > > I do 'not' see a hang on imx8mm-evk on 'usb start && usb tree' on
> > > > master (my other issue was on a 'usb stop' but only with usb
> > > > controllers in host mode).
> > > >
> > > > > This hang is a separate issue, not dt related, as far as I understand.
> > > > >
> > > > > The imx8mm dts sync does solve the issue of running 'ums' after
> > > > > CTRL+C.
> > > >
> > > > I don't agree. The hang 'is' related because all my imx8mm-venice-*
> > > > boards which use 'both' USB controllers hang with this patch on a 'usb
> > > > start' and don't hang without it. While a basic 'review' of the patch
> > > > looks good but actual product testing shows issues. As a maintainer
> > > > for ARM FREESCALE IMX you must have another imx8mm board which uses
> > > > both usbotg devices to test against and verify you see what I see?
> > > >
> > > > Until we know what other fix is needed to go along with this:
> > > > Nacked-by: Tim Harvey
> > >
> > > What is the harm is sync'ing the device tree with the kernel? I seemed
> > > like you found a solution with the regulator patch. Did I
> > > misunderstand that?
> > >
> > > adam
> >
> > Adam,
> >
> > No, the regulator patch did 'not' resolve the issue created by syncing
> > the imx8mm dt (I caused confusion by responding to the wrong thread -
> > the regulator patch resolved a different issue).
>
> Ok.
> >
> > Could you please verify my results on a board that uses both usbotg1
> > and usbotg2? What I see is on master + this imx8mm dt sync
> > (specifically the changes from Linux commit 4585c79ff477f ("arm64:
> > dts: imx8mm: correct usb power domains")) the board hangs on usb start
> > when bringing up usbotg2.
Adam,
Sorry to hear that :(
>
> I can, but I am about to board a plane to go visit some sick family,
> but I'll try to do it early next week.
> I have a board with both USB controllers enabled. My OTG2 is
> host-only, so I think it's similar to your setup.
Yes I think that is similar enough to test. In my experience simply
enabling otg2 via dt on imx8mm-evk shows the issue I see here but
Fabio says he sees a hang on 'usb start' even before this dt sync and
I don't know why my results on an imx8mm-evk differ.
>
> Should I apply the regulator patch when I test?
No, don't apply that as this exposes another issue: Error enabling
VBUS supply (ret=-114)
I'm still looking into that. I'm assuming when the regulaor refcnt
support gets merged it may expose a lot of issues from unbalanced
regulator enable/disable calls. The regulator refcnt series resolved
the hang I see on 'usb stop' for boards where otg2 is in host mode
(internal usb_hub device powers down the power domain before
ehci_shutdown tries to access the registers to disable the ports).
Tim
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 10:27 AM Tim Harvey wrote:
>
> On Fri, Apr 28, 2023 at 4:57 AM Adam Ford wrote:
> >
> > On Thu, Apr 27, 2023 at 5:25 PM Tim Harvey wrote:
> > >
> > > On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam wrote:
> > > >
> > > > On Thu, Apr 27, 2023 at 4:44 PM Tim Harvey
> > > > wrote:
> > > >
> > > > > Fabio,
> > > > >
> > > > > Sorry for the confusion.
> > > > >
> > > > > This imx8mm dt sync patch will hang on imx8mm boards that use 'both'
> > > > > usbotg1 and usbotg2. You can reproduce this hang on your imx8mm-evk by
> > > > > enabling usbotg2 in the dt (the board has it but it is not enabled due
> > > > > to the gpio based usb 3.0 mux not being sorted out yet):
> > > > > + {
> > > > > + dr_mode = "otg";
> > > > > + status = "okay";
> > > > > +};
> > > > > +
> > > > >
> > > > > u-boot=> usb start && usb tree
> > > > > starting USB...
> > > > > Bus usb@32e4: Bus usb@32e5:
> > > > > ^^^ imx8mm-evk hangs
> > > >
> > > > Yes, I can reproduce the hang, but it happens with or without the
> > > > imx8mm dt sync.
> > > >
> > >
> > > Fabio,
> > >
> > > I do 'not' see a hang on imx8mm-evk on 'usb start && usb tree' on
> > > master (my other issue was on a 'usb stop' but only with usb
> > > controllers in host mode).
> > >
> > > > This hang is a separate issue, not dt related, as far as I understand.
> > > >
> > > > The imx8mm dts sync does solve the issue of running 'ums' after CTRL+C.
> > >
> > > I don't agree. The hang 'is' related because all my imx8mm-venice-*
> > > boards which use 'both' USB controllers hang with this patch on a 'usb
> > > start' and don't hang without it. While a basic 'review' of the patch
> > > looks good but actual product testing shows issues. As a maintainer
> > > for ARM FREESCALE IMX you must have another imx8mm board which uses
> > > both usbotg devices to test against and verify you see what I see?
> > >
> > > Until we know what other fix is needed to go along with this:
> > > Nacked-by: Tim Harvey
> >
> > What is the harm is sync'ing the device tree with the kernel? I seemed
> > like you found a solution with the regulator patch. Did I
> > misunderstand that?
> >
> > adam
>
> Adam,
>
> No, the regulator patch did 'not' resolve the issue created by syncing
> the imx8mm dt (I caused confusion by responding to the wrong thread -
> the regulator patch resolved a different issue).
Ok.
>
> Could you please verify my results on a board that uses both usbotg1
> and usbotg2? What I see is on master + this imx8mm dt sync
> (specifically the changes from Linux commit 4585c79ff477f ("arm64:
> dts: imx8mm: correct usb power domains")) the board hangs on usb start
> when bringing up usbotg2.
I can, but I am about to board a plane to go visit some sick family,
but I'll try to do it early next week.
I have a board with both USB controllers enabled. My OTG2 is
host-only, so I think it's similar to your setup.
Should I apply the regulator patch when I test?
adam
>
> Best Regards,
>
> Tim
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 4:57 AM Adam Ford wrote:
>
> On Thu, Apr 27, 2023 at 5:25 PM Tim Harvey wrote:
> >
> > On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam wrote:
> > >
> > > On Thu, Apr 27, 2023 at 4:44 PM Tim Harvey wrote:
> > >
> > > > Fabio,
> > > >
> > > > Sorry for the confusion.
> > > >
> > > > This imx8mm dt sync patch will hang on imx8mm boards that use 'both'
> > > > usbotg1 and usbotg2. You can reproduce this hang on your imx8mm-evk by
> > > > enabling usbotg2 in the dt (the board has it but it is not enabled due
> > > > to the gpio based usb 3.0 mux not being sorted out yet):
> > > > + {
> > > > + dr_mode = "otg";
> > > > + status = "okay";
> > > > +};
> > > > +
> > > >
> > > > u-boot=> usb start && usb tree
> > > > starting USB...
> > > > Bus usb@32e4: Bus usb@32e5:
> > > > ^^^ imx8mm-evk hangs
> > >
> > > Yes, I can reproduce the hang, but it happens with or without the
> > > imx8mm dt sync.
> > >
> >
> > Fabio,
> >
> > I do 'not' see a hang on imx8mm-evk on 'usb start && usb tree' on
> > master (my other issue was on a 'usb stop' but only with usb
> > controllers in host mode).
> >
> > > This hang is a separate issue, not dt related, as far as I understand.
> > >
> > > The imx8mm dts sync does solve the issue of running 'ums' after CTRL+C.
> >
> > I don't agree. The hang 'is' related because all my imx8mm-venice-*
> > boards which use 'both' USB controllers hang with this patch on a 'usb
> > start' and don't hang without it. While a basic 'review' of the patch
> > looks good but actual product testing shows issues. As a maintainer
> > for ARM FREESCALE IMX you must have another imx8mm board which uses
> > both usbotg devices to test against and verify you see what I see?
> >
> > Until we know what other fix is needed to go along with this:
> > Nacked-by: Tim Harvey
>
> What is the harm is sync'ing the device tree with the kernel? I seemed
> like you found a solution with the regulator patch. Did I
> misunderstand that?
>
> adam
Adam,
No, the regulator patch did 'not' resolve the issue created by syncing
the imx8mm dt (I caused confusion by responding to the wrong thread -
the regulator patch resolved a different issue).
Could you please verify my results on a board that uses both usbotg1
and usbotg2? What I see is on master + this imx8mm dt sync
(specifically the changes from Linux commit 4585c79ff477f ("arm64:
dts: imx8mm: correct usb power domains")) the board hangs on usb start
when bringing up usbotg2.
Best Regards,
Tim
[PATCH] env: Remove misuse of env is nowhere driver
From: Stefan Herbrechtsmeier
When using a list of writeable variables, the initial values come from
the built-in default environment since commit 5ab81058364b
("env: Complete generic support for writable list"). Remove unnecessary
misuse of the env is nowhere driver as default environment.
Signed-off-by: Stefan Herbrechtsmeier
---
board/aristainetos/aristainetos.c| 19 ---
configs/aristainetos2c_defconfig | 1 -
configs/aristainetos2ccslb_defconfig | 1 -
env/env.c| 2 --
4 files changed, 23 deletions(-)
diff --git a/board/aristainetos/aristainetos.c
b/board/aristainetos/aristainetos.c
index 770f3d7d0d..35beda5cf5 100644
--- a/board/aristainetos/aristainetos.c
+++ b/board/aristainetos/aristainetos.c
@@ -529,22 +529,3 @@ int embedded_dtb_select(void)
return 0;
}
#endif
-
-enum env_location env_get_location(enum env_operation op, int prio)
-{
- if (op == ENVOP_SAVE || op == ENVOP_ERASE)
- return ENVL_SPI_FLASH;
-
- switch (prio) {
- case 0:
- return ENVL_NOWHERE;
-
- case 1:
- return ENVL_SPI_FLASH;
-
- default:
- return ENVL_UNKNOWN;
- }
-
- return ENVL_UNKNOWN;
-}
diff --git a/configs/aristainetos2c_defconfig b/configs/aristainetos2c_defconfig
index bd7947b46b..ec93284c20 100644
--- a/configs/aristainetos2c_defconfig
+++ b/configs/aristainetos2c_defconfig
@@ -58,7 +58,6 @@ CONFIG_OF_CONTROL=y
CONFIG_DTB_RESELECT=y
CONFIG_MULTI_DTB_FIT=y
CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_SPI_EARLY=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
diff --git a/configs/aristainetos2ccslb_defconfig
b/configs/aristainetos2ccslb_defconfig
index 3fb6e71c67..01d9169950 100644
--- a/configs/aristainetos2ccslb_defconfig
+++ b/configs/aristainetos2ccslb_defconfig
@@ -58,7 +58,6 @@ CONFIG_OF_CONTROL=y
CONFIG_DTB_RESELECT=y
CONFIG_MULTI_DTB_FIT=y
CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_SPI_EARLY=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
diff --git a/env/env.c b/env/env.c
index ad774f4117..2aa52c98f8 100644
--- a/env/env.c
+++ b/env/env.c
@@ -217,9 +217,7 @@ int env_load(void)
printf("OK\n");
gd->env_load_prio = prio;
-#if !CONFIG_IS_ENABLED(ENV_APPEND)
return 0;
-#endif
} else if (ret == -ENOMSG) {
/* Handle "bad CRC" case */
if (best_prio == -1)
--
2.30.2
Re: [PATCH 16/18] arm: dts: fsl-ls1088a: copy all missing bindings from Linux
On Fri, Apr 28, 2023 at 11:33:23AM +0800, Peng Fan wrote: > > > On 4/12/2023 3:38 PM, Mathew McBride wrote: > > This is effectively: > > > > cp linux/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi \ > > u-boot/arch/arm/dts/fsl-ls1088a.dtsi > > > > Tested working with Ten64 board (LS1088A) booting openSUSE Tumbleweed. > > > > Signed-off-by: Mathew McBride > > --- > > arch/arm/dts/fsl-ls1088a.dtsi | 320 -- > > 1 file changed, 304 insertions(+), 16 deletions(-) > > > > diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi > > index d5822520fb..e5fb137ac0 100644 > > --- a/arch/arm/dts/fsl-ls1088a.dtsi > > +++ b/arch/arm/dts/fsl-ls1088a.dtsi > > @@ -1,18 +1,27 @@ > > -// SPDX-License-Identifier: GPL-2.0+ OR X11 > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > I just relized that I overlooked this. Is it fine to update this？ > > I could drop this line change in my local if need to keep original license. As it's part of the re-sync it's fine. -- Tom signature.asc Description: PGP signature
Re: [PATCH 27/31] Makefile: Disable LTO when building with MSYS2
On Fri, Apr 28, 2023 at 09:37:57AM +0200, Marek Behún wrote: > On Thu, 27 Apr 2023 13:34:53 -0400 > Tom Rini wrote: > > > On Thu, Apr 27, 2023 at 10:25:13AM -0600, Simon Glass wrote: > > > Hi Pali, > > > > > > On Wed, 26 Apr 2023 at 01:07, Pali Rohár wrote: > > > > > > > > On Tuesday 25 April 2023 19:04:10 Simon Glass wrote: > > > > > Hi Pali, > > > > > > > > > > On Tue, 25 Apr 2023 at 10:28, Pali Rohár wrote: > > > > > > > > > > > > On Monday 24 April 2023 17:08:32 Simon Glass wrote: > > > > > > > This creates a lot of errors of the form: > > > > > > > > > > > > > > `__stack_chk_fail' referenced in section `.text' of ...ltrans.o: > > > > > > > defined > > > > > > >in discarded section `.text' of common/stackprot.o (symbol > > > > > > > from plugin) > > > > > > > > > > > > This issue should be rather fixed... > > > > > > > > > > > > > Drop LTO for now. > > > > > > > > > > > > ... and until it happens is not CONFIG_LTO for disabling enough? > > > > > > > > > > > > LTO does not work for more other boards / platforms and it is just > > > > > > _not_ > > > > > > enabled via CONFIG_LTO in those cases... > > > > > > > > > > The thing is, LTO is enabled for sandbox normally (clang and gcc). It > > > > > is just the MSYS2 platform where there are problems. > > > > > > > > So what about having CONFIG_LTO by default 'n' for CONFIG_MSYS2? > > > > > > But that would require creating a new board. I am trying to use the > > > same board, just building it in a different environment. > > > > I think we need to make CONFIG_LTO depend on CC_IS_GCC for now as it > > also doesn't work (but could be addressed) for CC_IS_CLANG. > > It got broken? It should work at least for sandbox... Ah right, we do clang + sandbox (so + LTO). In my clang for arm experiments, I could only get LTO to almost-link if I also used lld instead of GNU ld (on the platform I was checking there's some _other_ problem that causes clang's SPL build to be something like 40kB larger than gcc, so even with LTO it was still overflowing). -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] include: configs: am62x_evm: Use CONFIG_IS_ENABLED
On Fri, Apr 28, 2023 at 01:23:36PM +0530, Nikhil M Jain wrote: > Update to using CONFIG_IS_ENABLED and change DISTRO_BOOT_DEV_MMC to > first attempt SD card boot and next emmc boot. > > Signed-off-by: Nikhil M Jain > --- > include/configs/am62x_evm.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h > index 7bf07809b0..55ed2bc68f 100644 > --- a/include/configs/am62x_evm.h > +++ b/include/configs/am62x_evm.h > @@ -15,19 +15,19 @@ > /* DDR Configuration */ > #define CFG_SYS_SDRAM_BASE1 0x88000 > > -#ifdef CONFIG_CMD_MMC > -#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1) > +#if CONFIG_IS_ENABLED(CMD_MMC) > +#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 1) func(MMC, mmc, 0) > #else > #define DISTRO_BOOT_DEV_MMC(func) > #endif > > -#ifdef CONFIG_CMD_PXE > +#if CONFIG_IS_ENABLED(CMD_PXE) > #define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na) > #else > #define DISTRO_BOOT_DEV_PXE(func) > #endif > > -#ifdef CONFIG_CMD_DHCP > +#if CONFIG_IS_ENABLED(CMD_DHCP) > #define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na) > #else > #define DISTRO_BOOT_DEV_DHCP(func) Using CONFIG_IS_ENABLED is bad here, there's no context outside of full U-Boot where we have CMD_foo being possible. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] board: ti: am62x: Kconfig: Add ENV_SOIRCE_FILE for am62x
On Fri, Apr 28, 2023 at 01:23:34PM +0530, Nikhil M Jain wrote: > Set the base name for am62x to use am62x.env file, for setting > environment variable. > > Signed-off-by: Nikhil M Jain > --- > board/ti/am62x/Kconfig | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/board/ti/am62x/Kconfig b/board/ti/am62x/Kconfig > index 5e8dfa3cc4..b681d8e589 100644 > --- a/board/ti/am62x/Kconfig > +++ b/board/ti/am62x/Kconfig > @@ -34,6 +34,9 @@ config SYS_VENDOR > config SYS_CONFIG_NAME > default "am62x_evm" > > +config ENV_SOURCE_FILE > + default "am62x" > + > source "board/ti/common/Kconfig" > > endif Ugh, I see I didn't catch this on j721* in time. Please set this in the defconfig when needed. If we can't use CONFIG_SYS_BOARD.env for the common one, we should probably think a bit harder on what's named what. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/18] Synchronise LS1088A/Ten64 device tree with Linux
On Wed, Apr 12, 2023 at 07:38:12AM +, Mathew McBride wrote: > I am intensively working on updating the current > "production" Ten64 (NXP LS1088A) firmware from v2020.07 to > the latest U-Boot, with the hope of taking advantage of > bootstd/bootflow and other improvements. > > One desire I have is to have U-Boot "supply" the device tree > which is used for EFI boot, rather than our current method of > reading the DTB from a flash partition with commands (sf read etc.) > and plugging that into the distroboot process. > > Indeed, once we syncronise the U-Boot FDT with the Linux > one, the bootflow method "Just Works" with the control > FDT, without us having to plug an external FDT into the > process. > > (Note: the bootstd conversion for Ten64 will be coming in > a later commit. The DTS on it's own is only one part of > the puzzle) > > The flow of this series is: > - Fix a crash I found in the U-Boot FDT fixup for Layerscape > > The previous U-Boot copy of the fsl-ls1088a.dts did not > have direct alias to the "crypto" node, triggering a crash > when FDT fixup tried to operate on it. > > - Enable DM_SERIAL for Ten64 (mirrors how it was enabled for > LS1088A-RDB and LS1088A-QDS recently) > > - Move all U-Boot "tweaks" into a -u-boot.dtsi file. > Each board will have it's own -u-boot.dtsi, > which includs the SoC-specific fsl-ls1088a-u-boot.dtsi. > > - For all hardware that was in U-Boot's fsl-ls1088a.dtsi, > and not in the "correct" place (under /soc), move them > into /soc and adopt the Linux kernel definition. > > PCIe needed special treatment as it's U-Boot binding was > slightly different, as well as different compatible strings > (match a different U-Boot driver) for MDIO, USB and fsl-mc > among others. > > At this point, Linux is able to boot on the Ten64 > using U-Boot's FDT (passed to it via EFI) with > major hardware (Ethernet, USB, PCIe) functional. > > - Finally, copy over the U-Boot fsl-ls1088a.dtsi with the > Linux kernel version. > They are now bit-for-bit identical, with the U-Boot tweaks > contained externally. > > - Similarly for the Ten64 DTS - fsl-ls1088a-ten64.dts > is now identical to the kernel version. > > This builds upon the recent conversion of the LS1088A > to DM_SERIAL[1]. I used a similar syncronisation for the LS1028A[2] > as a guide. > > [1] - "Convert LS1088A and LX2160 to DM_SERIAL" patch series > https://patchwork.ozlabs.org/project/uboot/list/?series=346392=%2A=both > > [2] - "arm: dts: ls1028a: sync device tree with linux" patch series > https://patchwork.ozlabs.org/project/uboot/list/?series=265457=%2A=both > Thanks a lot, Mathew! I really appreciate the work that you put into this series. For the entire series: Reviewed-by: Ioana Ciornei Tested-by: Ioana Ciornei # on LS1088A-RDB Ioana
[PATCH 4/4] spi: pl022: Add chip-select gpio support
From: Lukas Funke
Add support for an optional external chip-select gpio.
Signed-off-by: Lukas Funke
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/spi/pl022_spi.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index 9e4caac16f..fc7388b379 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -12,9 +12,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#define SSP_CR00x000
@@ -70,6 +72,9 @@ struct pl022_spi_pdata {
fdt_addr_t addr;
fdt_size_t size;
unsigned int freq;
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ struct gpio_desc cs_gpio;
+#endif
};
struct pl022_spi_slave {
@@ -153,6 +158,17 @@ static int pl022_spi_release_bus(struct udevice *dev)
return 0;
}
+static void pl022_spi_set_cs(struct udevice *dev, bool on)
+{
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ struct udevice *bus = dev->parent;
+ struct pl022_spi_pdata *plat = dev_get_plat(bus);
+
+ if (dm_gpio_is_valid(>cs_gpio))
+ dm_gpio_set_value(>cs_gpio, on ? 1 : 0);
+#endif
+}
+
static int pl022_spi_xfer(struct udevice *dev, unsigned int bitlen,
const void *dout, void *din, unsigned long flags)
{
@@ -165,7 +181,7 @@ static int pl022_spi_xfer(struct udevice *dev, unsigned int
bitlen,
if (bitlen == 0)
/* Finish any previously submitted transfers */
- return 0;
+ goto done;
/*
* TODO: The controller can do non-multiple-of-8 bit
@@ -178,9 +194,13 @@ static int pl022_spi_xfer(struct udevice *dev, unsigned
int bitlen,
if (bitlen % 8) {
/* Errors always terminate an ongoing transfer */
flags |= SPI_XFER_END;
- return -1;
+ ret = -1;
+ goto done;
}
+ if (flags & SPI_XFER_BEGIN)
+ pl022_spi_set_cs(dev, true);
+
len = bitlen / 8;
while (len_tx < len) {
@@ -207,6 +227,10 @@ static int pl022_spi_xfer(struct udevice *dev, unsigned
int bitlen,
}
}
+done:
+ if (flags & SPI_XFER_END)
+ pl022_spi_set_cs(dev, false);
+
return ret;
}
@@ -309,6 +333,13 @@ static int pl022_spi_of_to_plat(struct udevice *bus)
plat->freq = clk_get_rate();
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ ret = gpio_request_by_name(bus, "cs-gpios", 0, >cs_gpio,
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+ if (ret < 0 && ret != -ENOENT)
+ return ret;
+#endif
+
return 0;
}
--
2.30.2
[PATCH 2/4] spi: pl022: Rename flush into pl022_spi_flush
From: Stefan Herbrechtsmeier
Rename the flush function into pl022_spi_flush to avoid conflicting
types with previous declaration of the function in stdio.h header.
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/spi/pl022_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index 2986c4eb5a..a6a0c552aa 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -107,7 +107,7 @@ static int pl022_spi_probe(struct udevice *bus)
return 0;
}
-static void flush(struct pl022_spi_slave *ps)
+static void pl022_spi_flush(struct pl022_spi_slave *ps)
{
do {
while (readw(ps->base + SSP_SR) & SSP_SR_MASK_RNE)
@@ -126,7 +126,7 @@ static int pl022_spi_claim_bus(struct udevice *dev)
reg |= SSP_CR1_MASK_SSE;
writew(reg, ps->base + SSP_CR1);
- flush(ps);
+ pl022_spi_flush(ps);
return 0;
}
@@ -137,7 +137,7 @@ static int pl022_spi_release_bus(struct udevice *dev)
struct pl022_spi_slave *ps = dev_get_priv(bus);
u16 reg;
- flush(ps);
+ pl022_spi_flush(ps);
/* Disable the SPI hardware */
reg = readw(ps->base + SSP_CR1);
--
2.30.2
[PATCH 1/4] spi: pl022: Align compatible property with device tree binding
From: Lukas Funke
Align the compatible property with the kernel device tree binding [1]
by removing the '-spi' suffix.
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-pl022.yaml
Signed-off-by: Lukas Funke
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/spi/pl022_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index 828eab3d34..2986c4eb5a 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -307,7 +307,7 @@ static int pl022_spi_of_to_plat(struct udevice *bus)
}
static const struct udevice_id pl022_spi_ids[] = {
- { .compatible = "arm,pl022-spi" },
+ { .compatible = "arm,pl022" },
{ }
};
#endif
--
2.30.2
[PATCH 3/4] spi: pl022: Remove platform data header
From: Stefan Herbrechtsmeier
Remove the platform data header because its content is only used by the
driver.
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/spi/pl022_spi.c | 8 +++-
include/dm/platform_data/spi_pl022.h | 21 -
2 files changed, 7 insertions(+), 22 deletions(-)
delete mode 100644 include/dm/platform_data/spi_pl022.h
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index a6a0c552aa..9e4caac16f 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -66,6 +66,12 @@
#define SSP_SR_MASK_RFF(0x1 << 3) /* Receive FIFO full */
#define SSP_SR_MASK_BSY(0x1 << 4) /* Busy Flag */
+struct pl022_spi_pdata {
+ fdt_addr_t addr;
+ fdt_size_t size;
+ unsigned int freq;
+};
+
struct pl022_spi_slave {
void *base;
unsigned int freq;
diff --git a/include/dm/platform_data/spi_pl022.h
b/include/dm/platform_data/spi_pl022.h
deleted file mode 100644
index 7f74b3cbc5..00
--- a/include/dm/platform_data/spi_pl022.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2018
- * Quentin Schulz, Bootlin, quentin.sch...@bootlin.com
- *
- * Structure for use with U_BOOT_DRVINFO for pl022 SPI devices or to use
- * in of_to_plat.
- */
-
-#ifndef __spi_pl022_h
-#define __spi_pl022_h
-
-#include
-
-struct pl022_spi_pdata {
- fdt_addr_t addr;
- fdt_size_t size;
- unsigned int freq;
-};
-
-#endif /* __spi_pl022_h */
--
2.30.2
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 5:25 PM Tim Harvey wrote:
>
> On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam wrote:
> >
> > On Thu, Apr 27, 2023 at 4:44 PM Tim Harvey wrote:
> >
> > > Fabio,
> > >
> > > Sorry for the confusion.
> > >
> > > This imx8mm dt sync patch will hang on imx8mm boards that use 'both'
> > > usbotg1 and usbotg2. You can reproduce this hang on your imx8mm-evk by
> > > enabling usbotg2 in the dt (the board has it but it is not enabled due
> > > to the gpio based usb 3.0 mux not being sorted out yet):
> > > + {
> > > + dr_mode = "otg";
> > > + status = "okay";
> > > +};
> > > +
> > >
> > > u-boot=> usb start && usb tree
> > > starting USB...
> > > Bus usb@32e4: Bus usb@32e5:
> > > ^^^ imx8mm-evk hangs
> >
> > Yes, I can reproduce the hang, but it happens with or without the
> > imx8mm dt sync.
> >
>
> Fabio,
>
> I do 'not' see a hang on imx8mm-evk on 'usb start && usb tree' on
> master (my other issue was on a 'usb stop' but only with usb
> controllers in host mode).
>
> > This hang is a separate issue, not dt related, as far as I understand.
> >
> > The imx8mm dts sync does solve the issue of running 'ums' after CTRL+C.
>
> I don't agree. The hang 'is' related because all my imx8mm-venice-*
> boards which use 'both' USB controllers hang with this patch on a 'usb
> start' and don't hang without it. While a basic 'review' of the patch
> looks good but actual product testing shows issues. As a maintainer
> for ARM FREESCALE IMX you must have another imx8mm board which uses
> both usbotg devices to test against and verify you see what I see?
>
> Until we know what other fix is needed to go along with this:
> Nacked-by: Tim Harvey
What is the harm is sync'ing the device tree with the kernel? I seemed
like you found a solution with the regulator patch. Did I
misunderstand that?
adam
>
> I've verified that it's the changes from Linux commit 4585c79ff477f
> ("arm64: dts: imx8mm: correct usb power domains") that causes the
> hang, but I don't know why yet.
>
> Why are we seeing different behavior on the imx8mm-evk? Are we on
> different branches? My testing today is on caf0a88d9f31
>
> Best Regards,
>
> Tim
Re: [PATCH v3 1/2] mtd: cfi: respect reg address length
Hi Stefan, On Fri, 2023-04-28 at 11:59 +0200, Stefan Roese wrote: > Hi Nuno Sá, > > On 4/26/23 16:16, Nuno Sá wrote: > > flash_get_size() will get the flash size from the device itself and go > > through all erase regions to read protection status. However, the device > > mappable region (eg: devicetree reg property) might be lower than the > > device full size which means that the above cycle will result in a data > > bus exception. This change fixes it by reading the 'addr_size' during > > probe() and also use that as one possible upper limit. > > > > Signed-off-by: Nuno Sá > > --- > > > > v2: > > * Fix compilation when CONFIG_CFI_FLASH is not set. Done by redefining > > cfi_flash_bank_size() when CONFIG_CFI_FLASH is set (by returning dts > > size). > > > > v3: > > * Fix another compilation warning by explicitly casting to unsigned > > long in cfi_flash_bank_size() > > > > Stefan, I did ran a world build [1] by opening a PR in github (to force CI > > to run). However I had to bypass the pytest stage (it was giving me some > > unrelated problems) and there are a couple of jobs failing but the > > errors apparently are not related to this patchset. Hopefully things now > > pass in your tests. > > > > [1]: https://github.com/u-boot/u-boot/pull/281 > > Unfortunately this breaks my usual Azure CI build in the test_py phase. > And this works without any issues without those 2 patches applied. So > its related to these changes. > Sorry for this... It seemed unrelated and the logs don't say much about why is it failing. I'll try to see what's the problem. - Nuno Sá
[PATCH v2] enable CONFIG_USE_BOOTCOMMAND
From: Srinuvasan A There is no default boot command set for de0-nano-soc. This results in simply dropping to the u-boot shell. With this, the target now automatically invokes distro_bootcmd to boot the kernel. Signed-off-by: Srinuvasan A --- configs/socfpga_de0_nano_soc_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/socfpga_de0_nano_soc_defconfig b/configs/socfpga_de0_nano_soc_defconfig index 364ae912ca..d48a9caa9a 100644 --- a/configs/socfpga_de0_nano_soc_defconfig +++ b/configs/socfpga_de0_nano_soc_defconfig @@ -15,7 +15,6 @@ CONFIG_TARGET_SOCFPGA_TERASIC_DE0_NANO=y CONFIG_FIT=y CONFIG_TIMESTAMP=y CONFIG_DISTRO_DEFAULTS=y -# CONFIG_USE_BOOTCOMMAND is not set CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_nano_soc.dtb" CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y -- 2.34.1
Re: [PATCH 02/18] configs: ten64: enable DM_SERIAL
On Wed, Apr 12, 2023 at 07:38:14AM +, Mathew McBride wrote: > The recent series "Convert LS1088A and LX2160 to DM_SERIAL" > from Ioana Ciornei provided the necessary support to enable > DM_SERIAL on the Ten64 board (LS1088A). > > Signed-off-by: Mathew McBride Reviewed-by: Ioana Ciornei Thanks! I didn't want to touch defconfigs which I cannot directly test on the board.
Re: [PATCH v2 00/17] rockchip: eMMC fixes for RK3568 and support for RK3588
On 4/27/23 21:27, Jonas Karlman wrote: On 2023-04-27 17:33, Eugen Hristev wrote: On 4/27/23 18:25, Jonas Karlman wrote: Hi Eugen, On 2023-04-27 16:45, Eugen Hristev wrote: On 4/18/23 19:46, Jonas Karlman wrote: This series fixes eMMC HS400 modes on RK3568 and add support for RK3588. It has been tested with rock-3a-rk3568/rock5b-rk3588 defconfig and CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_HS400_ES_SUPPORT=y CONFIG_MMC_SPEED_MODE_SET=y using the following command to switch mode and then read 512 MiB of data from eMMC into memory, => mmc dev 0 0 && mmc info && mmc read 1000 2000 1 for each of the modes below. 0 = MMC legacy 1 = MMC High Speed (26MHz) 3 = MMC High Speed (52MHz) 4 = MMC DDR52 (52MHz) 10 = HS200 (200MHz) 11 = HS400 (200MHz) 12 = HS400ES (200MHz) All reads have reported OK, prior to this some of these modes worked and others failed. Patch 1-2 fixes an issue with high-speed bit and uhs speed mode field. Patch 3-6 refactors the rk3568 driver to use set_clock and config_dll ops, so that clocks and regs are changed when output clock is disabled. Patch 7-10 continues refactoring and simplification of the driver. Patch 11-12 updates tap and delay values to fix HS400 modes on RK3568. Patch 13-15 adds support for RK3588 to driver and device tree. Patch 16-17 adds workarounds needed to use PIO mode in SPL to successfully load TF-A into SRAM when booting from eMMC on RK3588. Note that this series does not include any change to defconfigs to enable HS200/HS400/HS400ES modes. Changes in v2: - Add Signed-off-by tag and update commit message with a note from where reg-values originates from - Rename quirks to flags - Use driver data for hs200/hs400 txclk tapnum values - Change u-boot,dm-spl to bootph-pre-ram This series require working pinctrl, see [1]. A copy of this series and its dependencies can be found at [2]. [1] https://patchwork.ozlabs.org/project/uboot/patch/20230315153215.389809-1-eugen.hris...@collabora.com/ [2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-emmc-v2 Jonas Karlman (16): mmc: sdhci: Fix HISPD bit handling for MMC HS 52MHz mode mmc: sdhci: Set UHS Mode Select field for UHS SDR25 mode mmc: rockchip_sdhci: Fix use of device private data mmc: rockchip_sdhci: Remove unneeded emmc_phy_init ops mmc: rockchip_sdhci: Add set_clock and config_dll sdhci_ops mmc: rockchip_sdhci: Use set_clock and config_dll sdhci_ops mmc: rockchip_sdhci: Refactor execute tuning error handling mmc: rockchip_sdhci: Update speed mode controls in set_ios_post mmc: rockchip_sdhci: Remove empty get_phy and set_enhanced_strobe ops mmc: rockchip_sdhci: Rearrange and simplify used regs and flags mmc: rockchip_sdhci: Fix HS400 and HS400ES mode on RK3568 rockchip: rk3568-rock-3a: Enable support for more eMMC modes mmc: rockchip_sdhci: Add support for RK3588 rockchip: rk3588-rock-5b: Include eMMC node in SPL dtb clk: rockchip: rk3588: Add limited TMCLK_EMMC clock support mmc: rockchip_sdhci: Limit number of blocks read in a single command Peter Geis (1): mmc: sdhci: Allow disabling of SDMA in SPL arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 8 + arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 12 +- arch/arm/dts/rk3588s-u-boot.dtsi| 4 + configs/rock5b-rk3588_defconfig | 1 + drivers/clk/rockchip/clk_rk3588.c | 2 + drivers/mmc/Kconfig | 8 + drivers/mmc/rockchip_sdhci.c| 309 +--- drivers/mmc/sdhci.c | 13 +- 8 files changed, 215 insertions(+), 142 deletions(-) Hi Jonas, I saw in the logs you provided in the series that the SPL should also work in eMMC in rk3588, however, I am getting this error on my rock5b : Trying to boot from MMC2 spl: mmc boot mode: raw hdr read sector 4000, count=1 mmc_load_image_raw_sector: mmc block read error Do you have any idea of what's going wrong ? I know that there was some issue reading more then 4 sectors using CMD18. But here it looks like the initial 1 sector read using CMD17 fails. Try with CONFIG_MMC_VERBOSE=y, CONFIG_MMC_TRACE=y and CONFIG_LOGLEVEL=8 to get a little more detailed log. Yes I saw that from debug, it's the initial sector where the FIT should reside Please enable above configs and compare what CMD_SEND fails, here is current master branch with above 3 extra CONFIG enabled: https://gist.github.com/Kwiboo/56d82e2d7799331ff21999847a178657 CMD_SEND:17 ARG 0x4000 MMC_RSP_R1,5,6,7 0x0900 That should be the CMD17 that tries to read FIT image header from sector 0x4000. How far does yours gets? I did some debugging, then I got to understand that somehow I probably wasn't writing the u-boot.itb right as you said. Maybe rkdeveloptool has been playing tricks
Re: [PATCH v3 1/2] mtd: cfi: respect reg address length
Hi Nuno Sá,
On 4/26/23 16:16, Nuno Sá wrote:
flash_get_size() will get the flash size from the device itself and go
through all erase regions to read protection status. However, the device
mappable region (eg: devicetree reg property) might be lower than the
device full size which means that the above cycle will result in a data
bus exception. This change fixes it by reading the 'addr_size' during
probe() and also use that as one possible upper limit.
Signed-off-by: Nuno Sá
---
v2:
* Fix compilation when CONFIG_CFI_FLASH is not set. Done by redefining
cfi_flash_bank_size() when CONFIG_CFI_FLASH is set (by returning dts
size).
v3:
* Fix another compilation warning by explicitly casting to unsigned
long in cfi_flash_bank_size()
Stefan, I did ran a world build [1] by opening a PR in github (to force CI
to run). However I had to bypass the pytest stage (it was giving me some
unrelated problems) and there are a couple of jobs failing but the
errors apparently are not related to this patchset. Hopefully things now
pass in your tests.
[1]: https://github.com/u-boot/u-boot/pull/281
Unfortunately this breaks my usual Azure CI build in the test_py phase.
And this works without any issues without those 2 patches applied. So
its related to these changes.
Sorry, I can't apply these patches. Please take another look at fixing
these issues.
Thanks,
Stefan
[1]
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=298=results
drivers/mtd/cfi_flash.c | 11 +--
include/flash.h | 1 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index f378f6fb6139..87a3daebdabe 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -116,12 +116,16 @@ phys_addr_t cfi_flash_bank_addr(int i)
{
return flash_info[i].base;
}
+
+unsigned long cfi_flash_bank_size(int i)
+{
+ return (unsigned long)flash_info[i].addr_size;
+}
#else
__weak phys_addr_t cfi_flash_bank_addr(int i)
{
return ((phys_addr_t [])CFG_SYS_FLASH_BANKS_LIST)[i];
}
-#endif
__weak unsigned long cfi_flash_bank_size(int i)
{
@@ -131,6 +135,7 @@ __weak unsigned long cfi_flash_bank_size(int i)
return 0;
#endif
}
+#endif
__maybe_weak void flash_write8(u8 value, void *addr)
{
@@ -2492,15 +2497,17 @@ unsigned long flash_init(void)
static int cfi_flash_probe(struct udevice *dev)
{
fdt_addr_t addr;
+ fdt_size_t size;
int idx;
for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
- addr = dev_read_addr_index(dev, idx);
+ addr = dev_read_addr_size_index(dev, idx, );
if (addr == FDT_ADDR_T_NONE)
break;
flash_info[cfi_flash_num_flash_banks].dev = dev;
flash_info[cfi_flash_num_flash_banks].base = addr;
+ flash_info[cfi_flash_num_flash_banks].addr_size = size;
cfi_flash_num_flash_banks++;
}
gd->bd->bi_flashstart = flash_info[0].base;
diff --git a/include/flash.h b/include/flash.h
index 95992fa689bb..3710a2731b76 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -46,6 +46,7 @@ typedef struct {
#ifdef CONFIG_CFI_FLASH /* DM-specific parts */
struct udevice *dev;
phys_addr_t base;
+ phys_size_t addr_size;
#endif
} flash_info_t;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 2/3] board: ti: am62x: am62x: Update args_all env variable
On 4/28/2023 1:23 PM, Nikhil M Jain wrote:
> Remove the earlycon settings from args_all.
>
Could you explain why is it okay to drop earlycon?
Note, earlycon helps us to debug kernel crashes "before" kernel
initializes UART driver ... Its very useful to have it on by default
Regards
Vignesh
> Signed-off-by: Nikhil M Jain
> ---
> board/ti/am62x/am62x.env | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
> index e4e64fa637..cdd30b08ed 100644
> --- a/board/ti/am62x/am62x.env
> +++ b/board/ti/am62x/am62x.env
> @@ -7,8 +7,7 @@ findfdt=
> setenv fdtfile ${name_fdt}
> name_kern=Image
> console=ttyS2,115200n8
> -args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
> - ${mtdparts}
> +args_all=setenv optargs ${optargs} ${mtdparts}
> run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
>
> boot=mmc
Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts
On Friday 28 April 2023 15:39:20 Peng Fan wrote: > On 4/2/2023 12:43 AM, Pali Rohár wrote: > > Can anybody help with this? > > I expected Jaehoon would say some words. > > > > > On Saturday 25 March 2023 13:25:06 Pali Rohár wrote: > > > CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with > > > this issue? Expected usage is following: BootROM reads and execute SPL > > > from eMMC (BootROM has its own code for reading eMMC), SPL initialize > > > mmc driver and after SPL finish its work it returns control back to > > > BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue > > > is that after SPL returns control back to BootROM it looks like that > > > BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts > > > (timeout takes 5 minutes!) and after it correctly reads proper U-Boot > > > from eMMC and continues booting proper U-Boot. I guess that there is an > > > issue that SPL's mmc driver changes eMMC state into something which > > > BootROM does not expect. > > A general question is since BootROM will still using eMMC, why let > SPL to initialize eMMC? SPL's configuration may not match ROM's expection. Requirement is ENV access which is stored on eMMC too and without initializing SPL eMMC driver, SPL cannot access ENV. Another thing is that loading proper U-Boot via SPL eMMC driver is sometimes faster than via BootROM eMMC code. I guess this is BootROM does not full speed. Also another fact is that SPL on mvebu works in this "hybrid" mode (initialize and access boot device; plus let BootROM to use it) for all other bootable storages. > For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask > ROM help loading images, and SPL not touch relevant USB/EMMC. Unfortunately there is no BootROM API for these processors. All issues which are being resolved in this (and also other) discussions are done by inspecting BootROM code and trying to understand how it behaves and how it choose the eMMC boot partition. As this stuff has poor documentation and even this documentation has documented erratas... So nobody knows what exactly is and what not supported. What we need to do is to write mvebu specific SPL code which is compatible with BootROM. > Regards, > Peng. > > > > > > > On Friday 24 March 2023 02:55:55 Martin Rowe wrote: > > > > On Thu, 23 Mar 2023 at 19:01, Pali Rohár wrote: > > > > > There is issue with that 5 minutes delay. But I think it should be > > > > > fixed > > > > > by the patch which I sent earlier, which restore partition config > > > > > based > > > > > on mmc->part_config in board_return_to_bootrom(). Could you test it? > > > > > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/ > > > > > Now when mmc->part_config is correctly initialized it should restore > > > > > configuration and BootROM does not have to get that "Timeout waiting > > > > > card ready" error. > > > > > > > > Still takes about 5 minutes. The output is below with MMC tracing. I > > > > confirmed the value of mmc->part_config used for > > > > restore_emmc_boot_part_config is the same as what is initially > > > > detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and > > > > zeroed boot0). > > > > > > > > ERROR: Invalid kwbimage v1 > > > > mmc_load_image_raw_sector: mmc block read error > > > > spl: mmc: wrong boot mode > > > > Trying to boot from BOOTROM > > > > CMD_SEND:6 > > > > ARG 0x03b30a00 > > > > MMC_RSP_R1b 0x0900 > > > > CMD_SEND:13 > > > > ARG 0x0001 > > > > MMC_RSP_R1,5,6,7 0x0900 > > > > CURR STATE:4 > > > > Returning to BootROM (return address 0x05c4)... > > > > > > I looked at the BootROM disassembled code and error message > > > "Timeout waiting card ready" is printed when following mmc command > > > cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts. > > > > > > 0xd is in U-Boot MMC_CMD_SEND_STATUS > > > > > > 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY > > > which looks like U-Boot's MMC_RSP_R2 with BUSY bit set > > > > > > It looks like U-Boot function mmc_send_status() where that "something" > > > in cmdarg is mmc->rca. > > > > > > If command does not timeout then BootROM next checks if response has > > > BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are > > > truth then BootROM mark call as successful. > > > > > > If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints > > > "Status Error: " with hex response value and mark call as unsuccessful. > > > > > > I'm looking at the U-Boot code and this BootROM logic looks very similar > > > to U-Boot function mmc_poll_for_busy(), just without first call > > > mmc_wait_dat0(). > > > > > > BIT(8) is MMC_STATUS_RDY_FOR_DATA > > > 0x1e00 is MMC_STATUS_CURR_STATE > > > 0xe00 is MMC_STATE_PRG > > > 0xfdf94080 is MMC_STATUS_MASK > > > > > > I'm not mmc expert, but this looks like
[PATCH 3/3] include: configs: am62x_evm: Use CONFIG_IS_ENABLED
Update to using CONFIG_IS_ENABLED and change DISTRO_BOOT_DEV_MMC to first attempt SD card boot and next emmc boot. Signed-off-by: Nikhil M Jain --- include/configs/am62x_evm.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h index 7bf07809b0..55ed2bc68f 100644 --- a/include/configs/am62x_evm.h +++ b/include/configs/am62x_evm.h @@ -15,19 +15,19 @@ /* DDR Configuration */ #define CFG_SYS_SDRAM_BASE10x88000 -#ifdef CONFIG_CMD_MMC -#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1) +#if CONFIG_IS_ENABLED(CMD_MMC) +#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 1) func(MMC, mmc, 0) #else #define DISTRO_BOOT_DEV_MMC(func) #endif -#ifdef CONFIG_CMD_PXE +#if CONFIG_IS_ENABLED(CMD_PXE) #define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na) #else #define DISTRO_BOOT_DEV_PXE(func) #endif -#ifdef CONFIG_CMD_DHCP +#if CONFIG_IS_ENABLED(CMD_DHCP) #define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na) #else #define DISTRO_BOOT_DEV_DHCP(func) -- 2.34.1
[PATCH 2/3] board: ti: am62x: am62x: Update args_all env variable
Remove the earlycon settings from args_all.
Signed-off-by: Nikhil M Jain
---
board/ti/am62x/am62x.env | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index e4e64fa637..cdd30b08ed 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -7,8 +7,7 @@ findfdt=
setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
-args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
- ${mtdparts}
+args_all=setenv optargs ${optargs} ${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
boot=mmc
--
2.34.1
[PATCH 1/3] board: ti: am62x: Kconfig: Add ENV_SOIRCE_FILE for am62x
Set the base name for am62x to use am62x.env file, for setting environment variable. Signed-off-by: Nikhil M Jain --- board/ti/am62x/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/board/ti/am62x/Kconfig b/board/ti/am62x/Kconfig index 5e8dfa3cc4..b681d8e589 100644 --- a/board/ti/am62x/Kconfig +++ b/board/ti/am62x/Kconfig @@ -34,6 +34,9 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "am62x_evm" +config ENV_SOURCE_FILE + default "am62x" + source "board/ti/common/Kconfig" endif @@ -52,6 +55,9 @@ config SYS_CONFIG_NAME config SPL_LDSCRIPT default "arch/arm/mach-omap2/u-boot-spl.lds" +config ENV_SOURCE_FILE + default "am62x" + source "board/ti/common/Kconfig" endif -- 2.34.1
[PATCH 0/3] Update env support for Am62x
This patch series aims at updating the env support on Am62x by adding necessary config, updating env variables, update to using CONFIG_IS_ENABLED. Nikhil M Jain (3): board: ti: am62x: Kconfig: Add ENV_SOIRCE_FILE for am62x board: ti: am62x: am62x: Update args_all env variable include: configs: am62x_evm: Use CONFIG_IS_ENABLED board/ti/am62x/Kconfig | 6 ++ board/ti/am62x/am62x.env| 3 +-- include/configs/am62x_evm.h | 8 3 files changed, 11 insertions(+), 6 deletions(-) -- 2.34.1
[PATCH 1/1] doc: man-page for cp
Add a man-page for the cp command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/cp.rst | 83 doc/usage/index.rst | 1 + 2 files changed, 84 insertions(+) create mode 100644 doc/usage/cmd/cp.rst diff --git a/doc/usage/cmd/cp.rst b/doc/usage/cmd/cp.rst new file mode 100644 index 00..897c0bb7df --- /dev/null +++ b/doc/usage/cmd/cp.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +cp command +== + +Synopsis + + +:: + +mm source target count +mm.b source target count +mm.w source target count +mm.l source target count +mm.q source target count + +Description +--- + +The cp command is used to copy *count* words of memory from the *source* +address to the *target* address. If the *target* address points to NOR flash, +the flash is programmed. + +The word size is defined by the suffix defaulting to 32 bits: + +== +suffix word size +== +.b 8 bit words +.w 16 bit words +.l 32 bit words +.q 64 bit words + 32 bit words +== + +source +source address, hexadecimal + +target +target address, hexadecimal + +count +number of words to be copied, hexadecimal + +Examples + + +The example device has a NOR flash where the lower part of the flash is +protected. We first copy to RAM, then to unprotected flash. Last we try to +write to protectd flash. + +:: + +=> mtd list +List of MTD devices: +* nor0 + - device: flash@0 + - parent: root_driver + - driver: cfi_flash + - path: /flash@0 + - type: NOR flash + - block size: 0x2 bytes + - min I/O: 0x1 bytes + - 0x-0x0200 : "nor0" +=> cp.b 402 500 20 +=> cp.b 402 1e0 2 +Copy to Flash... done +=> cp.b 402 0 2 +Copy to Flash... Can't write to protected Flash sectors +=> + +Configuration +- + +The cp command is available if CONFIG_CMD_MEMORY=y. Support for 64 bit words +(cp.q) depends on CONFIG_MEM_SUPPORT_64BIT_DATA=y. Copying to flash depends on +CONFIG_MTD_NOR_FLASH=y. + +Return value + + +The return value $? is set to 0 (true) if the command was successfully, +1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index cdf710919a..0fde130a54 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -41,6 +41,7 @@ Shell commands cmd/cmp cmd/coninfo cmd/conitrace + cmd/cp cmd/cyclic cmd/dm cmd/ebtupdate -- 2.39.2
Re: [PATCH v5 1/3] regulator: implement basic reference counter
On 4/28/23 02:39, Tim Harvey wrote:
On Wed, Apr 19, 2023 at 6:45 AM Eugen Hristev
wrote:
Some devices share a regulator supply, when the first one will request
regulator disable, the second device will have it's supply cut off before
graciously shutting down. Hence there will be timeouts and other failed
operations.
Implement a reference counter mechanism similar with what is done in
Linux, to keep track of enable and disable requests, and only disable the
regulator when the last of the consumers has requested shutdown.
Signed-off-by: Eugen Hristev
Reviewed-by: Simon Glass
---
Changes in v5:
- none
Changes in v4:
- add documentation for error codes
Changes in v3:
- add error return codes
Changes in v2:
- add info in header regarding the function
drivers/power/regulator/regulator_common.c | 22 ++
drivers/power/regulator/regulator_common.h | 21 +
2 files changed, 43 insertions(+)
diff --git a/drivers/power/regulator/regulator_common.c
b/drivers/power/regulator/regulator_common.c
index 93d8196b381e..484a4fc31ef7 100644
--- a/drivers/power/regulator/regulator_common.c
+++ b/drivers/power/regulator/regulator_common.c
@@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice *dev,
return 0;
}
+ /* If previously enabled, increase count */
+ if (enable && dev_pdata->enable_count > 0) {
+ dev_pdata->enable_count++;
+ return -EALREADY;
+ }
+
+ if (!enable) {
+ if (dev_pdata->enable_count > 1) {
+ /* If enabled multiple times, decrease count */
+ dev_pdata->enable_count--;
+ return -EBUSY;
+ } else if (!dev_pdata->enable_count) {
+ /* If already disabled, do nothing */
+ return -EALREADY;
+ }
+ }
+
Eugen,
Thank you for working on this series!
Hi Tim,
Thank you for testing and having a look on my patches.
I wonder if instead of returning a failure you should print an error
here but return 0 in order to not break unbalanced regulator calls
Initially I did that, but Simon forced me to return error as you see now.
(like what is done in clk_disable()). I see that you have another
patch in this series which handles htis for
regulator_set_enable_if_allowed() but that doesn't cover drivers that
call regulator_common_set_enable() directly such as
drivers/power/regulator/fixed.c and
drivers/power/regulator/gpio-regulator.c.
I believe Jonas (in CC) fixed those with a patch, but at the moment I am
lost in providing you a link to it
I know there is an unbalanced call currently on imx8mm that this patch
causes a failure where it previously did not:
u-boot=> usb start && usb tree
starting USB...
Bus usb@32e4: Bus usb@32e5: Error enabling VBUS supply (ret=-114)
probe failed, error -114
That's a good catch.
I expected such things would happen if I would return error in those
cases, so it might be that this is not the only case.
If you are able to test that board, do you wish me to send you a patch
that changes the code to using regulator_set_enable_if_allowed() ?
Best Regards,
Tim
Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts
On 4/2/2023 12:43 AM, Pali Rohár wrote: Can anybody help with this? I expected Jaehoon would say some words. On Saturday 25 March 2023 13:25:06 Pali Rohár wrote: CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with this issue? Expected usage is following: BootROM reads and execute SPL from eMMC (BootROM has its own code for reading eMMC), SPL initialize mmc driver and after SPL finish its work it returns control back to BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue is that after SPL returns control back to BootROM it looks like that BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts (timeout takes 5 minutes!) and after it correctly reads proper U-Boot from eMMC and continues booting proper U-Boot. I guess that there is an issue that SPL's mmc driver changes eMMC state into something which BootROM does not expect. A general question is since BootROM will still using eMMC, why let SPL to initialize eMMC? SPL's configuration may not match ROM's expection. For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask ROM help loading images, and SPL not touch relevant USB/EMMC. Regards, Peng. On Friday 24 March 2023 02:55:55 Martin Rowe wrote: On Thu, 23 Mar 2023 at 19:01, Pali Rohár wrote: There is issue with that 5 minutes delay. But I think it should be fixed by the patch which I sent earlier, which restore partition config based on mmc->part_config in board_return_to_bootrom(). Could you test it? https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/ Now when mmc->part_config is correctly initialized it should restore configuration and BootROM does not have to get that "Timeout waiting card ready" error. Still takes about 5 minutes. The output is below with MMC tracing. I confirmed the value of mmc->part_config used for restore_emmc_boot_part_config is the same as what is initially detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and zeroed boot0). ERROR: Invalid kwbimage v1 mmc_load_image_raw_sector: mmc block read error spl: mmc: wrong boot mode Trying to boot from BOOTROM CMD_SEND:6 ARG 0x03b30a00 MMC_RSP_R1b 0x0900 CMD_SEND:13 ARG 0x0001 MMC_RSP_R1,5,6,7 0x0900 CURR STATE:4 Returning to BootROM (return address 0x05c4)... I looked at the BootROM disassembled code and error message "Timeout waiting card ready" is printed when following mmc command cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts. 0xd is in U-Boot MMC_CMD_SEND_STATUS 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY which looks like U-Boot's MMC_RSP_R2 with BUSY bit set It looks like U-Boot function mmc_send_status() where that "something" in cmdarg is mmc->rca. If command does not timeout then BootROM next checks if response has BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are truth then BootROM mark call as successful. If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints "Status Error: " with hex response value and mark call as unsuccessful. I'm looking at the U-Boot code and this BootROM logic looks very similar to U-Boot function mmc_poll_for_busy(), just without first call mmc_wait_dat0(). BIT(8) is MMC_STATUS_RDY_FOR_DATA 0x1e00 is MMC_STATUS_CURR_STATE 0xe00 is MMC_STATE_PRG 0xfdf94080 is MMC_STATUS_MASK I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing in BootROM after U-Boot returns control back to the BootROM.
Re: [PATCH 27/31] Makefile: Disable LTO when building with MSYS2
On Thu, 27 Apr 2023 13:34:53 -0400 Tom Rini wrote: > On Thu, Apr 27, 2023 at 10:25:13AM -0600, Simon Glass wrote: > > Hi Pali, > > > > On Wed, 26 Apr 2023 at 01:07, Pali Rohár wrote: > > > > > > On Tuesday 25 April 2023 19:04:10 Simon Glass wrote: > > > > Hi Pali, > > > > > > > > On Tue, 25 Apr 2023 at 10:28, Pali Rohár wrote: > > > > > > > > > > On Monday 24 April 2023 17:08:32 Simon Glass wrote: > > > > > > This creates a lot of errors of the form: > > > > > > > > > > > > `__stack_chk_fail' referenced in section `.text' of ...ltrans.o: > > > > > > defined > > > > > >in discarded section `.text' of common/stackprot.o (symbol from > > > > > > plugin) > > > > > > > > > > This issue should be rather fixed... > > > > > > > > > > > Drop LTO for now. > > > > > > > > > > ... and until it happens is not CONFIG_LTO for disabling enough? > > > > > > > > > > LTO does not work for more other boards / platforms and it is just > > > > > _not_ > > > > > enabled via CONFIG_LTO in those cases... > > > > > > > > The thing is, LTO is enabled for sandbox normally (clang and gcc). It > > > > is just the MSYS2 platform where there are problems. > > > > > > So what about having CONFIG_LTO by default 'n' for CONFIG_MSYS2? > > > > But that would require creating a new board. I am trying to use the > > same board, just building it in a different environment. > > I think we need to make CONFIG_LTO depend on CC_IS_GCC for now as it > also doesn't work (but could be addressed) for CC_IS_CLANG. > It got broken? It should work at least for sandbox... Marek
Re: atmel_sdhci: SDMMC_CD pin still needed for card detection despite EMMC set to non-removable
Hi Zixun Li,
On 4/27/23 22:51, Zixun Li wrote:
Hardware: SAMA5D27 customized board, EMMC connected to SDMMC0. SDMMC0_CD pin
pulled-down for BootROM card detection, once booted it used as LED output.
Software: u-boot-at91 76f7f55
Issue:
U-Boot can't detect EMMC despite it set to non-removable in DT, unless
SDMMC0_CD pin is used (so this pin can't be used for other purpose)
sdmmc0: sdio-host@a000 {
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 =
<_sdmmc0_default>;
status = "okay";
non-removable;
no-1-8-v;
};
Workaround: I have to FCD bit of SDMMC_MC1R register.
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 766e4a6b0c..89ceeaf3c1 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -758,7 +758,12 @@ static int sdhci_get_cd(struct udevice *dev)
/* If nonremovable, assume that the card is always present. */
if (mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
+ {
+ value = sdhci_readb(host, SDHCI_HOST_MC1R);
+ sdhci_writeb(host, SDHCI_VENDOR_MC1R_FCD | value,
SDHCI_HOST_MC1R);
return 1;
+ }
+
Can you find some place to set this bit in the atmel sdhci driver, and
not in the core?
The MC1R register is specific to at91 device.
Eugen
/* If polling, assume that the card is always present. */
if (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL)
return 1;
diff --git a/include/sdhci.h b/include/sdhci.h
index c718dd7206..61e7ebb2a1 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -223,6 +223,9 @@
#define SDHCI_GET_VERSION(x) (x->version & SDHCI_SPEC_VER_MASK)
+#define SDHCI_HOST_MC1R0x204
+
+#define SDHCI_VENDOR_MC1R_FCD 0x80
/*
* End of controller registers.
*/
Re: [PATCH 1/1] cmd/sbi: display new extensions
On Wed, Apr 12, 2023 at 10:38:16AM +0200, Heinrich Schuchardt wrote: > OpenSBI already implements some extensions that are not ratified yet: > > * Debug Console Extension (DBCN) > * System Suspend Extension (SUSP) > * Collaborative Processor Performance Control Extension (CPPC) > > Allow the sbi command to display these. > > Provide the FID definitions of the Debug Console Extension. We can use that > extension for an early debug console driver. > > Signed-off-by: Heinrich Schuchardt > --- > arch/riscv/include/asm/sbi.h | 9 + > cmd/riscv/sbi.c | 3 +++ > 2 files changed, 12 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH] board: starfive: Fixed errors reported when executing get_maintainer.pl
On Fri, Apr 28, 2023 at 09:28:20AM +0800, Yanhong Wang wrote: > Fixed errors reported when executing 'scripts/get_maintainer.pl -f > configs/starfive_visionfive2_defconfig'. > > Invalid MAINTAINERS address: 'startfive' > > Signed-off-by: Yanhong Wang > --- > board/starfive/visionfive2/MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Leo Yu-Chi Liang
