Re: [PATCH 2/3] rockchip: fix wrong PCI range address in rk3568 dtsi
Hi Quentin, Le 24/06/2024 à 15:15, Quentin Schulz a écrit : Hi Etienne, On 6/24/24 2:40 PM, ETIENNE DUBLE wrote: One of the PCI ranges was wrong in this device tree. When testing with a FriendlyElec Nanopi R5C board, the 2nd ethernet interface (labelled "wan") was not working in u-boot because of that. With the correct value (found in FriendlyElec's downstream u-boot repository), this 2nd ethernet interface now works. Signed-off-by: Etienne Dublé --- dts/upstream/src/arm64/rockchip/rk3568.dtsi | 2 +- dts/upstream is only for patches coming from **merged** Linux kernel (i.e. releases or -rc releases or master branch from Linus Torvalds). We do not accept U-Boot-only patches in dts/upstream. Please submit the patch to the Linux kernel first and it will eventually make it to that directory either via a dts/update-dts-subtree.sh pull or dts/update-dts-subtree.sh pick. Depending on maintainer's opinion, fixing the range in arch/arm/dts/rk3568-u-boot.dtsi could be an option, but we really need the patch sent to upstream Linux kernel community first. c.f. https://www.kernel.org/doc/html/v6.5/process/submitting-patches.html I see, I will look at it. In version 2 of the series I will remove this second patch and just mention that we are waiting for this problem to be fixed upstream, in the cover letter. Cheers, Etienne -- Etienne Dublé CNRS / LIG - Bâtiment IMAG 700 avenue Centrale - 38401 St Martin d'Hères Bureau 426 - Tel 0457421431
Re: [PATCH 1/3] net: give a different name to rtl8169 interfaces
Hi Quentin,
Thanks for reviewing my patches.
Le 24/06/2024 à 15:08, Quentin Schulz a écrit :
[...]
1 file changed, 11 insertions(+)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 93e83661ce..b30d51731f 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -1091,6 +1091,16 @@ static int rtl8169_eth_probe(struct udevice *dev)
return 0;
}
+static int rtl8169_eth_bind(struct udevice *dev)
+{
+ static int card_number;
+ char name[16];
+
+ sprintf(name, "RTL8169#%u", card_number++);
+
+ return device_set_name(dev, name);
+}
+
I don't think we can guarantee bind order so this may not be stable
over time.
I'm wondering if there isn't a way to use the "ethernet" (ethernet0,
ethernet1) alias in DT instead?
Actually the ethernet interfaces are not declared in the device tree,
only PCI buses are (at least on this Nanopi board).
The ethernet interfaces are only detected when running "pci enum".
Another option may be to name them "rtl8169@", with ""
reflecting the PCI region address (so it is unique and stable). What do
you think?
Cheers,
Etienne
--
Etienne Dublé
CNRS / LIG - Bâtiment IMAG
700 avenue Centrale - 38401 St Martin d'Hères
Bureau 426 - Tel 0457421431
Re: [PATCH v4 10/14] net-lwip: add wget command
Jerome Forissier writes:
> On 6/24/24 08:21, Jon Humphreys wrote:
>> Jerome Forissier writes:
>>
>>> Add support for the wget command with NET_LWIP.
>>>
>>> Based on code initially developed by Maxim U.
>>>
>>> Signed-off-by: Jerome Forissier
>>> Co-developed-by: Maxim Uvarov
>>> Cc: Maxim Uvarov
>>> Signed-off-by: Jerome Forissier
>>> ---
>>> cmd/Kconfig| 7 ++
>>> cmd/net-lwip.c | 8 ++
>>> include/net-lwip.h | 18 +++
>>> net-lwip/Makefile | 1 +
>>> net-lwip/wget.c| 269 +
>>> 5 files changed, 303 insertions(+)
>>> create mode 100644 net-lwip/wget.c
>>>
>>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>>> index 6ef0b52cd34..d9a86540be6 100644
>>> --- a/cmd/Kconfig
>>> +++ b/cmd/Kconfig
>>> @@ -2117,6 +2117,13 @@ config CMD_TFTPBOOT
>>> help
>>> tftpboot - load file via network using TFTP protocol
>>>
>>> +config CMD_WGET
>>> + bool "wget"
>>> + select PROT_TCP_LWIP
>>> + help
>>> + wget is a simple command to download kernel, or other files,
>>> + from a http server over TCP.
>>> +
>>> endif
>>>
>>> endif
>>> diff --git a/cmd/net-lwip.c b/cmd/net-lwip.c
>>> index c021da6a674..42f8bd6b259 100644
>>> --- a/cmd/net-lwip.c
>>> +++ b/cmd/net-lwip.c
>>> @@ -35,3 +35,11 @@ U_BOOT_CMD(
>>> "hostname [envvar]"
>>> );
>>> #endif
>>> +
>>> +#if defined(CONFIG_CMD_WGET)
>>> +U_BOOT_CMD(
>>> + wget, 3, 1, do_wget,
>>> + "boot image via network using HTTP protocol",
>>> + "[loadAddress] URL"
>>> +);
>>> +#endif
>>> diff --git a/include/net-lwip.h b/include/net-lwip.h
>>> index 4d41b0208a3..ddf25e61417 100644
>>> --- a/include/net-lwip.h
>>> +++ b/include/net-lwip.h
>>> @@ -11,8 +11,26 @@ struct netif *net_lwip_new_netif_noip(void);
>>> void net_lwip_remove_netif(struct netif *netif);
>>> struct netif *net_lwip_get_netif(void);
>>>
>>> +/**
>>> + * wget_with_dns() - runs dns host IP address resulution before wget
>>> + *
>>> + * @dst_addr: destination address to download the file
>>> + * @uri: uri string of target file of wget
>>> + * Return: downloaded file size, negative if failed
>>> + */
>>> +
>>> +int wget_with_dns(ulong dst_addr, char *uri);
>>> +/**
>>> + * wget_validate_uri() - varidate the uri
>>> + *
>>> + * @uri: uri string of target file of wget
>>> + * Return: true if uri is valid, false if uri is invalid
>>> + */
>>> +bool wget_validate_uri(char *uri);
>>> +
>>> int do_dhcp(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>>> int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>>> int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>>> +int do_wget(struct cmd_tbl *cmdtp, int flag, int argc, char * const
>>> argv[]);
>>>
>>> #endif /* __NET_LWIP_H__ */
>>> diff --git a/net-lwip/Makefile b/net-lwip/Makefile
>>> index aa247859483..bc011bb0e32 100644
>>> --- a/net-lwip/Makefile
>>> +++ b/net-lwip/Makefile
>>> @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_DHCP) += dhcp.o
>>> obj-$(CONFIG_CMD_DNS) += dns.o
>>> obj-$(CONFIG_CMD_PING) += ping.o
>>> obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
>>> +obj-$(CONFIG_CMD_WGET) += wget.o
>>>
>>> # Disable this warning as it is triggered by:
>>> # sprintf(buf, index ? "foo%d" : "foo", index)
>>> diff --git a/net-lwip/wget.c b/net-lwip/wget.c
>>> new file mode 100644
>>> index 000..069299bd469
>>> --- /dev/null
>>> +++ b/net-lwip/wget.c
>>> @@ -0,0 +1,269 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/* Copyright (C) 2024 Linaro Ltd. */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define SERVER_NAME_SIZE 200
>>> +#define HTTP_PORT_DEFAULT 80
>>> +#define PROGRESS_PRINT_STEP_BYTES (100 * 1024)
>>> +
>>> +enum done_state {
>>> +NOT_DONE = 0,
>>> +SUCCESS = 1,
>>> +FAILURE = 2
>>> +};
>>> +
>>> +struct wget_ctx {
>>> + ulong daddr;
>>> + ulong saved_daddr;
>>> + ulong size;
>>> + ulong prevsize;
>>> + ulong start_time;
>>> + enum done_state done;
>>> +};
>>> +
>>> +static int parse_url(char *url, char *host, u16 *port, char **path)
>>> +{
>>> + char *p, *pp;
>>> + long lport;
>>> +
>>> + p = strstr(url, "http://";);
>>> + if (!p)
>>> + return -EINVAL;
>>> +
>>> + p += strlen("http://";);
>>> +
>>> + /* Parse hostname */
>>> + pp = strchr(p, ':');
>>> + if (!pp)
>>> + pp = strchr(p, '/');
>>> + if (!pp)
>>> + return -EINVAL;
>>> +
>>> + if (p + SERVER_NAME_SIZE <= pp)
>>> + return -EINVAL;
>>> +
>>> + memcpy(host, p, pp - p);
>>> + host[pp - p + 1] = '\0';
>>> +
>>> + if (*pp == ':') {
>>> + /* Parse port number */
>>> + p = pp + 1;
>>> + lport = simple_strtol(p, &pp, 10);
>>> + if (pp && *pp != '/')
>>> + return -EINVAL;
>>> + if (lport > 65535)
>>> + return -EINVAL;
>>> + *port = (u1
Re: [PATCH] imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
On 6/24/24 10:20 AM, Paul Geurts wrote: The decision on whether HAB is enabled is solely based on the SEC_CONFIG fuse. The HAB FIELD_RETURN feature is able to permanently disable HAB on a CPU, after which it is able to boot unsigned firmware. U-Boot however does not take into account the FIELD_RETURN mode, and refuses to boot unsigned software when the feature is enabled. Also take the FIELD_RETURN fuse into account when deciding whether HAB is enabled. When The FIELD_RETURN fuse is blown, HAB is not enabled. Tested on i.MX8M Mini, i.MX8M Plus, i.MX8M Nano and i.MX6ULL The purpose of the field return fuse is to unlock a system when it is returned to factory, right ? That is the intention of the field return mode indeed. Can the system be re-locked afterward too ? No, the field return is enabled by a fuse, which cannot be reverted. The mode is intended to be able to perform investigations on broken devices, but these devices are not intended to go back into the field. Understood, thanks for clarifying.
Re: [PATCH v3 4/6] buildman: Always use the full path in CROSS_COMPILE
On Sun, Jun 23, 2024 at 11:56:20AM -0600, Simon Glass wrote:
> The feature to set the toolchain path does not seem to be needed. It
> causes problems with venv (see [1]). Let's remove it.
>
> Add some tests while we are here.
>
> It does not look like any docs changes are needed for this.
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20240621131423.2363294-6-...@chromium.org/
>
> Signed-off-by: Simon Glass
> Suggested-by: Tom Rini
> ---
>
> Changes in v3:
> - Drop the PATH modification altogether
>
> tools/buildman/bsettings.py | 3 ++
> tools/buildman/builder.py | 5 +--
> tools/buildman/builderthread.py | 4 +-
> tools/buildman/cmdline.py | 2 -
> tools/buildman/control.py | 6 +--
> tools/buildman/test.py | 75 +
> tools/buildman/toolchain.py | 20 -
> 7 files changed, 92 insertions(+), 23 deletions(-)
>
> diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py
> index e225ac2ca0f..1be1d45e0fa 100644
> --- a/tools/buildman/bsettings.py
> +++ b/tools/buildman/bsettings.py
> @@ -31,6 +31,9 @@ def setup(fname=''):
> def add_file(data):
> settings.readfp(io.StringIO(data))
>
> +def add_section(name):
> +settings.add_section(name)
> +
> def get_items(section):
> """Get the items from a section of the config.
>
> diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
> index f35175b4598..7c563cddada 100644
> --- a/tools/buildman/builder.py
> +++ b/tools/buildman/builder.py
> @@ -255,7 +255,7 @@ class Builder:
>
> def __init__(self, toolchains, base_dir, git_dir, num_threads, num_jobs,
> gnu_make='make', checkout=True, show_unknown=True, step=1,
> - no_subdirs=False, full_path=False, verbose_build=False,
> + no_subdirs=False, verbose_build=False,
> mrproper=False, per_board_out_dir=False,
> config_only=False, squash_config_y=False,
> warnings_as_errors=False, work_in_output=False,
> @@ -279,8 +279,6 @@ class Builder:
> step: 1 to process every commit, n to process every nth commit
> no_subdirs: Don't create subdirectories when building current
> source for a single board
> -full_path: Return the full path in CROSS_COMPILE and don't set
> -PATH
> verbose_build: Run build with V=1 and don't use 'make -s'
> mrproper: Always run 'make mrproper' when configuring
> per_board_out_dir: Build in a separate persistent directory per
> @@ -336,7 +334,6 @@ class Builder:
> self._step = step
> self._error_lines = 0
> self.no_subdirs = no_subdirs
> -self.full_path = full_path
> self.verbose_build = verbose_build
> self.config_only = config_only
> self.squash_config_y = squash_config_y
> diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
> index a8599c0bb2a..c23c3254d2d 100644
> --- a/tools/buildman/builderthread.py
> +++ b/tools/buildman/builderthread.py
> @@ -404,7 +404,7 @@ class BuilderThread(threading.Thread):
> the next incremental build
> """
> # Set up the environment and command line
> -env = self.toolchain.MakeEnvironment(self.builder.full_path)
> +env = self.toolchain.MakeEnvironment()
> mkdir(out_dir)
>
> args, cwd, src_dir = self._build_args(brd, out_dir, out_rel_dir,
> @@ -569,7 +569,7 @@ class BuilderThread(threading.Thread):
> outf.write(f'{result.return_code}')
>
> # Write out the image and function size information and an
> objdump
> -env = result.toolchain.MakeEnvironment(self.builder.full_path)
> +env = result.toolchain.MakeEnvironment()
> with open(os.path.join(build_dir, 'out-env'), 'wb') as outf:
> for var in sorted(env.keys()):
> outf.write(b'%s="%s"' % (var, env[var]))
> diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
> index 03211bd5aa5..5fda90508f2 100644
> --- a/tools/buildman/cmdline.py
> +++ b/tools/buildman/cmdline.py
> @@ -121,8 +121,6 @@ def add_after_m(parser):
>help="Override host toochain to use for sandbox (e.g. 'clang-7')")
> parser.add_argument('-Q', '--quick', action='store_true',
>default=False, help='Do a rough build, with limited warning
> resolution')
> -parser.add_argument('-p', '--full-path', action='store_true',
> - default=False, help="Use full toolchain path in CROSS_COMPILE")
> parser.add_argument('-P', '--per-board-out-dir', action='store_true',
>default=False, help="Use an O= (output) directory per board rather
> than per thread")
> parser.add_argument('--print-arch', action='store_true',
> diff --git a/tools/buildman/control.py b/tools/buildman/control.py
>
Re: [PATCH 25/42] test: Allow connecting to a running board
On Tue, Jun 11, 2024 at 02:01:39PM -0600, Simon Glass wrote:
> Sometimes we know that the board is already running the right software,
> so provide an option to allow running of tests directly, without first
> resetting the board.
>
> This saves time when re-running a test where only the Python code is
> changing.
>
> Signed-off-by: Simon Glass
> ---
>
> test/py/conftest.py | 3 +++
> test/py/u_boot_console_base.py| 14 ++
> test/py/u_boot_console_exec_attach.py | 21 -
> 3 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/test/py/conftest.py b/test/py/conftest.py
> index fc9dd3a83f8..ca66b9d9e61 100644
> --- a/test/py/conftest.py
> +++ b/test/py/conftest.py
> @@ -79,6 +79,8 @@ def pytest_addoption(parser):
> parser.addoption('--gdbserver', default=None,
> help='Run sandbox under gdbserver. The argument is the channel '+
> 'over which gdbserver should communicate, e.g. localhost:1234')
> +parser.addoption('--no-prompt-wait', default=False, action='store_true',
> +help="Assume that U-Boot is ready and don't wait for a prompt")
>
> def run_build(config, source_dir, build_dir, board_type, log):
> """run_build: Build U-Boot
> @@ -238,6 +240,7 @@ def pytest_configure(config):
> ubconfig.board_type = board_type
> ubconfig.board_identity = board_identity
> ubconfig.gdbserver = gdbserver
> +ubconfig.no_prompt_wait = config.getoption('no_prompt_wait')
> ubconfig.dtb = build_dir + '/arch/sandbox/dts/test.dtb'
>
> env_vars = (
> diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
> index e4f86f6af5b..a61eec31148 100644
> --- a/test/py/u_boot_console_base.py
> +++ b/test/py/u_boot_console_base.py
> @@ -413,11 +413,17 @@ class ConsoleBase(object):
> if not self.config.gdbserver:
> self.p.timeout = TIMEOUT_MS
> self.p.logfile_read = self.logstream
> -if expect_reset:
> -loop_num = 2
> +if self.config.no_prompt_wait:
> +# Send an empty command to set up the 'expect' logic. This
> has
> +# the side effect of ensuring that there was no partial
> command
> +# line entered
> +self.run_command(' ')
> else:
> -loop_num = 1
> -self.wait_for_boot_prompt(loop_num = loop_num)
> +if expect_reset:
> +loop_num = 2
> +else:
> +loop_num = 1
> +self.wait_for_boot_prompt(loop_num = loop_num)
Hi Simon,
I had a very bad day, so here you go:
== ?
/Andrejs
> self.at_prompt = True
> self.at_prompt_logevt = self.logstream.logfile.cur_evt
> except Exception as ex:
> diff --git a/test/py/u_boot_console_exec_attach.py
> b/test/py/u_boot_console_exec_attach.py
> index 5f4916b7da2..42fc15197b9 100644
> --- a/test/py/u_boot_console_exec_attach.py
> +++ b/test/py/u_boot_console_exec_attach.py
> @@ -59,15 +59,18 @@ class ConsoleExecAttach(ConsoleBase):
> args = [self.config.board_type, self.config.board_identity]
> s = Spawn(['u-boot-test-console'] + args)
>
> -try:
> -self.log.action('Resetting board')
> -cmd = ['u-boot-test-reset'] + args
> -runner = self.log.get_runner(cmd[0], sys.stdout)
> -runner.run(cmd)
> -runner.close()
> -except:
> -s.close()
> -raise
> +if self.config.no_prompt_wait:
> +self.log.action('Connecting to board without reset')
> +else:
> +try:
> +self.log.action('Resetting board')
> +cmd = ['u-boot-test-reset'] + args
> +runner = self.log.get_runner(cmd[0], sys.stdout)
> +runner.run(cmd)
> +runner.close()
> +except:
> +s.close()
> +raise
>
> return s
>
> --
> 2.34.1
>
Re: [PATCH v4 00/14] Introduce the lwIP network stack
On Sat, Jun 22, 2024 at 1:09 AM Maxim Uvarov wrote: > > пт, 21 июн. 2024 г. в 21:42, Fabio Estevam : > > > > Hi Tim and Jerome, > > > > On Fri, Jun 21, 2024 at 1:08 PM Tim Harvey wrote: > > > > > I tried your to-upstream/v5-wip branch > > > (042bea36eb9731079a3d7afffe3774d79e06ac5d) and it behaves the same. Do > > > you have something else to try/test? > > > > Yes, when I tested older versions from Maxim I could never get lwIP to > > work with i.MX. > > > > Jerome, > > > > Please try to run the lwIP series on any i.MX board, if possible. > > > > Thanks > > Packet not for us means that incoming packet DST MAC does not match to > the MAC address inside lwip. I.e. to MAC address set into lwip when > lwip_init was done. Original U-Boot network stack does not compare > MACs but lwip does. There is something specific on this board, in > general lwip with debug should print out > MAC used during initialization. This MAC should match to the MAC from > the incoming packet. > It seems 'packet not for us' can mean a lot of things. I added a bit of debugging around 'DHCP packet accepted' and found I'm not receiving any packets from my DHCP server. So I connected directly to another board (isolated network) where I ran my own server and tcpdump and I don't see packets coming from lwip: without lwip my server shows: # tcpdump -i eth1 tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 22:18:01.043992 IP (tos 0x0, ttl 255, id 23, offset 0, flags [DF], proto UDP (17), length 328) 22:18:01.044391 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 22:18:01.044454 IP (tos 0x0, ttl 255, id 24, offset 0, flags [DF], proto UDP (17), length 328) 22:18:01.044752 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) # tcpdump -i eth1 tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 22:22:41.602178 [|llc] 22:22:41.709978 [|llc] 22:22:41.867947 [|llc] 22:22:42.105202 [|llc] 22:22:42.502091 [|llc] 22:22:43.219079 [|llc] 22:22:44.497979 [|llc] 22:22:45.776884 [|llc] 22:22:47.054773 [|llc] 22:22:48.333667 [|llc] 22:22:49.611559 [|llc] 22:22:50.890469 [|llc] What actual hardware has this been tested with? I think Tom mentioned he tested with an rpi of some sort. I don't know what the meaning of the llc msg is above but you can see there is no DHCP request. Best Regards, Tim
Re: [PATCH v2] fs: btrfs: fix out of bounds write
On Tue, Jun 25, 2024 at 01:22:01AM +0300, Alex ThreeD wrote:
> Hi all,
>
> Is there something on my side needed to push this forward?
I will pick it up for -next in a while, thanks.
>
> On Wed, Jun 19, 2024 at 12:41 AM Alex Shumsky wrote:
>
> > Fix btrfs_read/read_and_truncate_page write out of bounds of destination
> > buffer. Old behavior break bootstd malloc'd buffers of exact file size.
> > Previously this OOB write have not been noticed because distroboot usually
> > read files into huge static memory areas.
> >
> > Signed-off-by: Alex Shumsky
> > Fixes: e342718 ("fs: btrfs: Implement btrfs_file_read()")
> > ---
> >
> > Changes in v2:
> > - fix error path handling
> > - add Fixes tag
> > - use min3
> >
> > fs/btrfs/inode.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> > index 4691612eda..3998ffc2c8 100644
> > --- a/fs/btrfs/inode.c
> > +++ b/fs/btrfs/inode.c
> > @@ -640,7 +640,11 @@ static int read_and_truncate_page(struct btrfs_path
> > *path,
> > extent_type = btrfs_file_extent_type(leaf, fi);
> > if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
> > ret = btrfs_read_extent_inline(path, fi, buf);
> > - memcpy(dest, buf + page_off, min(page_len, ret));
> > + if (ret < 0) {
> > + free(buf);
> > + return ret;
> > + }
> > + memcpy(dest, buf + page_off, min3(page_len, ret, len));
> > free(buf);
> > return len;
> > }
> > @@ -652,7 +656,7 @@ static int read_and_truncate_page(struct btrfs_path
> > *path,
> > free(buf);
> > return ret;
> > }
> > - memcpy(dest, buf + page_off, page_len);
> > + memcpy(dest, buf + page_off, min(page_len, len));
> > free(buf);
> > return len;
> > }
> > --
> > 2.34.1
> >
> >
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] fs: btrfs: fix out of bounds write
Hi all,
Is there something on my side needed to push this forward?
On Wed, Jun 19, 2024 at 12:41 AM Alex Shumsky wrote:
> Fix btrfs_read/read_and_truncate_page write out of bounds of destination
> buffer. Old behavior break bootstd malloc'd buffers of exact file size.
> Previously this OOB write have not been noticed because distroboot usually
> read files into huge static memory areas.
>
> Signed-off-by: Alex Shumsky
> Fixes: e342718 ("fs: btrfs: Implement btrfs_file_read()")
> ---
>
> Changes in v2:
> - fix error path handling
> - add Fixes tag
> - use min3
>
> fs/btrfs/inode.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 4691612eda..3998ffc2c8 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -640,7 +640,11 @@ static int read_and_truncate_page(struct btrfs_path
> *path,
> extent_type = btrfs_file_extent_type(leaf, fi);
> if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
> ret = btrfs_read_extent_inline(path, fi, buf);
> - memcpy(dest, buf + page_off, min(page_len, ret));
> + if (ret < 0) {
> + free(buf);
> + return ret;
> + }
> + memcpy(dest, buf + page_off, min3(page_len, ret, len));
> free(buf);
> return len;
> }
> @@ -652,7 +656,7 @@ static int read_and_truncate_page(struct btrfs_path
> *path,
> free(buf);
> return ret;
> }
> - memcpy(dest, buf + page_off, page_len);
> + memcpy(dest, buf + page_off, min(page_len, len));
> free(buf);
> return len;
> }
> --
> 2.34.1
>
>
[PATCH 9/9] doc: introduce led.rst documentation
Introduce simple led.rst documentation to document all the additional
Kconfig and the current limitation of LED_BLINK and GPIO software blink.
Signed-off-by: Christian Marangi
---
doc/api/index.rst | 1 +
doc/api/led.rst | 10 ++
include/led.h | 38 ++
3 files changed, 49 insertions(+)
create mode 100644 doc/api/led.rst
diff --git a/doc/api/index.rst b/doc/api/index.rst
index 51b2013af36..6f11b94eac3 100644
--- a/doc/api/index.rst
+++ b/doc/api/index.rst
@@ -13,6 +13,7 @@ U-Boot API documentation
event
getopt
interrupt
+ led
linker_lists
lmb
logging
diff --git a/doc/api/led.rst b/doc/api/led.rst
new file mode 100644
index 000..e52e350d1bb
--- /dev/null
+++ b/doc/api/led.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+LED
+===
+
+.. kernel-doc:: include/led.h
+ :doc: Overview
+
+.. kernel-doc:: include/led.h
+ :internal:
\ No newline at end of file
diff --git a/include/led.h b/include/led.h
index 409397e1df9..4dac54338e4 100644
--- a/include/led.h
+++ b/include/led.h
@@ -7,6 +7,44 @@
#ifndef __LED_H
#define __LED_H
+/**
+ * DOC: Overview
+ *
+ * Generic LED API provided when a supported compatible is defined in
DeviceTree.
+ *
+ * To enable support for LEDs, enable the `CONFIG_LED` Kconfig option.
+ *
+ * The most common implementation is for GPIO-connected LEDs. If using
GPIO-connected LEDs,
+ * enable the `LED_GPIO` Kconfig option.
+ *
+ * `LED_BLINK` support requires LED driver support and is therefore optional.
If LED blink
+ * functionality is needed, enable the `LED_BLINK` Kconfig option.
+ *
+ * GPIO-connected LEDs can simulate blinking via software using the Cyclic
API. To utilize this,
+ * enable `CONFIG_LED_GPIO_SW_BLINK`. This will also select `CONFIG_LED_BLINK`
and `CONFIG_CYCLIC`.
+ *
+ * Boot and Activity LEDs are also supported. These LEDs can signal various
system operations
+ * during runtime, such as boot initialization, file transfers, and flash
write/erase operations.
+ *
+ * To enable a Boot LED, enable `CONFIG_LED_BOOT_ENABLE` and define
`CONFIG_LED_BOOT_LABEL`. This
+ * will enable the specified LED to blink and turn ON when the bootloader
initializes correctly.
+ *
+ * To enable an Activity LED, enable `CONFIG_LED_ACTIVITY_ENABLE` and define
+ * `CONFIG_LED_ACTIVITY_LABEL`.
+ * This will enable the specified LED to blink and turn ON during file
transfers or flash
+ * write/erase operations.
+ *
+ * Both Boot and Activity LEDs provide a simple API to turn the LED ON or OFF:
+ * `led_boot_on()`, `led_boot_off()`, `led_activity_on()`, and
`led_activity_off()`.
+ *
+ * Both configurations can optionally define a `_PERIOD` option if
`CONFIG_LED_BLINK` is enabled
+ * for LED blink operations, which is usually used by the Activity LED.
+ *
+ * When `CONFIG_LED_BLINK` is enabled, additional APIs are exposed:
`led_boot_blink()` and
+ * `led_activity_blink()`. Note that if `CONFIG_LED_BLINK` is disabled, these
APIs will behave
+ * like the `led_boot_on()` and `led_activity_on()` APIs, respectively.
+ */
+
struct udevice;
enum led_state_t {
--
2.45.1
[PATCH 8/9] ubi: implement support for LED activity
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal ubi write operation.
Signed-off-by: Christian Marangi
---
cmd/ubi.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/cmd/ubi.c b/cmd/ubi.c
index 8c1b5df0572..984be3da4af 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -416,7 +417,19 @@ int ubi_volume_begin_write(char *volume, void *buf, size_t
size,
int ubi_volume_write(char *volume, void *buf, size_t size)
{
- return ubi_volume_begin_write(volume, buf, size, size);
+ int ret;
+
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ led_activity_blink();
+#endif
+
+ ret = ubi_volume_begin_write(volume, buf, size, size);
+
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ led_activity_off();
+#endif
+
+ return ret;
}
int ubi_volume_read(char *volume, char *buf, size_t size)
--
2.45.1
[PATCH 7/9] mtd: implement support for LED activity
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal mtd write or erase operations.
Signed-off-by: Christian Marangi
---
cmd/mtd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/cmd/mtd.c b/cmd/mtd.c
index 795aaa2b37d..ba5ee0d4d71 100644
--- a/cmd/mtd.c
+++ b/cmd/mtd.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#if CONFIG_IS_ENABLED(CMD_MTD_OTP)
#include
#endif
@@ -558,6 +559,11 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
argc,
while (mtd_block_isbad(mtd, off))
off += mtd->erasesize;
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ if (!read)
+ led_activity_blink();
+#endif
+
/* Loop over the pages to do the actual read/write */
while (remaining) {
/* Skip the block if it is bad */
@@ -585,6 +591,11 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
argc,
io_op.oobbuf += io_op.oobretlen;
}
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ if (!read)
+ led_activity_off();
+#endif
+
if (!ret && dump)
mtd_dump_device_buf(mtd, start_off, buf, len, woob);
@@ -652,6 +663,10 @@ static int do_mtd_erase(struct cmd_tbl *cmdtp, int flag,
int argc,
erase_op.addr = off;
erase_op.len = mtd->erasesize;
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ led_activity_blink();
+#endif
+
while (len) {
if (!scrub) {
ret = mtd_block_isbad(mtd, erase_op.addr);
@@ -680,6 +695,10 @@ static int do_mtd_erase(struct cmd_tbl *cmdtp, int flag,
int argc,
erase_op.addr += mtd->erasesize;
}
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ led_activity_off();
+#endif
+
if (ret && ret != -EIO)
ret = CMD_RET_FAILURE;
else
--
2.45.1
[PATCH 6/9] tftp: implement support for LED activity
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal traffic.
Signed-off-by: Christian Marangi
---
net/tftp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/tftp.c b/net/tftp.c
index 6b16bdcbe4c..1d6609342a9 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,6 +193,9 @@ static void new_transfer(void)
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ led_activity_blink();
+#endif
}
#ifdef CONFIG_CMD_TFTPPUT
@@ -301,6 +305,9 @@ static void tftp_complete(void)
time_start * 1000, "/s");
}
puts("\ndone\n");
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+ led_activity_off();
+#endif
if (!tftp_put_active)
efi_set_bootdev("Net", "", tftp_filename,
map_sysmem(tftp_load_addr, 0),
--
2.45.1
[PATCH 5/9] led: implement LED activity API
Implement LED activity API similar to BOOT LED API.
Usual activity might be a file transfer with TFTP, a flash write...
User of this API will call led_activity_on/off/blink() to signal these
kind of activity.
New Kconfig are implemented similar to BOOT LED, LED_ACTIVITY_ENABLE to
enable support for it, LED_ACTIVITY_LABEL to assign the LED in DT for
activity usage and LED_ACTIVITY_PERIOD to set the blinking period.
Signed-off-by: Christian Marangi
---
drivers/led/Kconfig | 23 +++
include/led.h | 40
2 files changed, 63 insertions(+)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 0506a33b6ee..f53e5fb5bd3 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -31,6 +31,29 @@ config LED_BOOT_PERIOD
Value is normalized per CONFIG_SYS_HZ.
+config LED_ACTIVITY_ENABLE
+ bool "Enable LED activity support"
+ help
+ Enable LED activity support.
+
+ LED activity is a specific LED assigned to signal activity operation
+ like file trasnfer, flash write/erase...
+
+config LED_ACTIVITY_LABEL
+ string "LED activity label"
+ depends on LED_ACTIVITY_ENABLE
+ help
+ LED label defined in DT to assign for LED activity usage.
+
+config LED_ACTIVITY_PERIOD
+ int "LED activity period"
+ depends on LED_ACTIVITY_ENABLE && LED_BLINK
+ default 2
+ help
+ LED activity blink period in ms.
+
+ Value is normalized per CONFIG_SYS_HZ.
+
config LED_BCM6328
bool "LED Support for BCM6328"
depends on LED && ARCH_BMIPS
diff --git a/include/led.h b/include/led.h
index 479c6d17c5b..409397e1df9 100644
--- a/include/led.h
+++ b/include/led.h
@@ -176,4 +176,44 @@ static inline int led_boot_blink(void)
#endif
#endif
+#ifdef CONFIG_LED_ACTIVITY_ENABLE
+
+#define LED_ACTIVITY_PERIOD CONFIG_SYS_HZ / CONFIG_LED_ACTIVITY_PERIOD
+
+/**
+ * led_activity_on() - turn ON the designated LED for activity
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static inline int led_activity_on(void)
+{
+ return led_set_state_by_label(CONFIG_LED_ACTIVITY_LABEL, LEDST_ON);
+}
+
+/**
+ * led_activity_off() - turn OFF the designated LED for activity
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static inline int led_activity_off(void)
+{
+ return led_set_state_by_label(CONFIG_LED_ACTIVITY_LABEL, LEDST_OFF);
+}
+
+#ifdef CONFIG_LED_BLINK
+/**
+ * led_activity_blink() - turn ON the designated LED for activity
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static inline int led_activity_blink(void)
+{
+ return led_set_period_by_label(CONFIG_LED_ACTIVITY_LABEL,
LED_BOOT_PERIOD);
+}
+#else
+/* If LED BLINK is not supported/enabled, fallback to LED ON */
+#define led_activity_blink led_activity_on
+#endif
+#endif
+
#endif
--
2.45.1
[PATCH 4/9] common: board_r: rework BOOT LED handling
Rework BOOT LED handling. There is currently one legacy implementation
for BOOT LED from Status Led API.
This work on ancient implementation wused by BOOTP by setting the LED
to Blink on boot and to turn it OFF when the firmware was correctly
received by network.
Now that we new LED implementation have support for LED boot, rework
this by also set the new BOOT LED to blink and also set it to ON before
entering main loop to confirm successful boot.
Signed-off-by: Christian Marangi
---
common/board_r.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c
index c823cd262f1..6a4dacdea88 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -463,14 +464,30 @@ static int initr_malloc_bootparams(void)
#if defined(CONFIG_LED_STATUS)
static int initr_status_led(void)
{
-#if defined(CONFIG_LED_STATUS_BOOT)
- status_led_set(CONFIG_LED_STATUS_BOOT, CONFIG_LED_STATUS_BLINKING);
-#else
status_led_init();
+
+ return 0;
+}
+#endif
+
+static int initr_boot_led_blink(void)
+{
+#ifdef CONFIG_LED_STATUS_BOOT
+ status_led_set(CONFIG_LED_STATUS_BOOT, CONFIG_LED_STATUS_BLINKING);
+#endif
+#ifdef CONFIG_LED_BOOT_ENABLE
+ led_boot_blink();
#endif
return 0;
}
+
+static int initr_boot_led_on(void)
+{
+#ifdef CONFIG_LED_BOOT_ENABLE
+ led_boot_on();
#endif
+ return 0;
+}
#ifdef CONFIG_CMD_NET
static int initr_net(void)
@@ -717,6 +734,7 @@ static init_fnc_t init_sequence_r[] = {
#if defined(CONFIG_LED_STATUS)
initr_status_led,
#endif
+ initr_boot_led_blink,
/* PPC has a udelay(20) here dating from 2002. Why? */
#ifdef CONFIG_BOARD_LATE_INIT
board_late_init,
@@ -739,6 +757,7 @@ static init_fnc_t init_sequence_r[] = {
#if defined(CFG_PRAM)
initr_mem,
#endif
+ initr_boot_led_on,
run_main_loop,
};
--
2.45.1
[PATCH 3/9] led: implement LED boot API
Implement LED boot API to signal correct boot of the system.
led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the
designated boot LED.
New Kconfig are introduced, CONFIG_LED_BOOT_ENABLE to enable the feature,
CONFIG_LED_BOOT_LABEL to declare the LED label in DT to reference
the LED for BOOT usage and CONFIG_LED_BOOT_PERIOD to declare the
blinking period.
If CONFIG_LED_BLINK is not enabled, led_boot_blink call will fallback to
simple LED ON.
Signed-off-by: Christian Marangi
---
drivers/led/Kconfig | 22 ++
include/led.h | 40
2 files changed, 62 insertions(+)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 13d6eb40cea..0506a33b6ee 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -9,6 +9,28 @@ config LED
can provide access to board-specific LEDs. Use of the device tree
for configuration is encouraged.
+config LED_BOOT_ENABLE
+ bool "Enable LED boot support"
+ help
+ Enable LED boot support.
+
+ LED boot is a specific LED assigned to signal boot operation status.
+
+config LED_BOOT_LABEL
+ string "LED boot label"
+ depends on LED_BOOT_ENABLE
+ help
+ LED label defined in DT to assign for LED boot usage.
+
+config LED_BOOT_PERIOD
+ int "LED boot period"
+ depends on LED_BOOT_ENABLE && LED_BLINK
+ default 2
+ help
+ LED boot blink period in ms.
+
+ Value is normalized per CONFIG_SYS_HZ.
+
config LED_BCM6328
bool "LED Support for BCM6328"
depends on LED && ARCH_BMIPS
diff --git a/include/led.h b/include/led.h
index 71dd7a28d93..479c6d17c5b 100644
--- a/include/led.h
+++ b/include/led.h
@@ -136,4 +136,44 @@ int led_set_period_by_label(const char *label, int
period_ms);
*/
int led_bind_generic(struct udevice *parent, const char *driver_name);
+#ifdef CONFIG_LED_BOOT_ENABLE
+
+#define LED_BOOT_PERIOD CONFIG_SYS_HZ / CONFIG_LED_BOOT_PERIOD
+
+/**
+ * led_boot_on() - turn ON the designated LED for booting
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static inline int led_boot_on(void)
+{
+ return led_set_state_by_label(CONFIG_LED_BOOT_LABEL, LEDST_ON);
+}
+
+/**
+ * led_boot_off() - turn OFF the designated LED for booting
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static inline int led_boot_off(void)
+{
+ return led_set_state_by_label(CONFIG_LED_BOOT_LABEL, LEDST_OFF);
+}
+
+#ifdef CONFIG_LED_BLINK
+/**
+ * led_boot_blink() - turn ON the designated LED for booting
+ *
+ * Return: 0 if OK, -ve on error
+ */
+static inline int led_boot_blink(void)
+{
+ return led_set_period_by_label(CONFIG_LED_BOOT_LABEL, LED_BOOT_PERIOD);
+}
+#else
+/* If LED BLINK is not supported/enabled, fallback to LED ON */
+#define led_boot_blink led_boot_on
+#endif
+#endif
+
#endif
--
2.45.1
[PATCH 2/9] led: implement led_set_state/paeriod_by_label
Introduce new API led_set_state/period_by label as a shorthand to set
LED state and LED blink period by referencing them by label.
This is needed for the upcoming additional API that will declare LED in
.confg and reference them by their LED label name.
Signed-off-by: Christian Marangi
---
drivers/led/led-uclass.c | 28
include/led.h| 18 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index f37bf6a1550..d1e9916bb33 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -61,6 +61,20 @@ int led_set_state(struct udevice *dev, enum led_state_t
state)
return ops->set_state(dev, state);
}
+int led_set_state_by_label(const char *label, enum led_state_t state)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = led_get_by_label(label, &dev);
+ if (ret) {
+ printf("Failed to get LED by label %s\n", label);
+ return ret;
+ }
+
+ return led_set_state(dev, state);
+}
+
enum led_state_t led_get_state(struct udevice *dev)
{
struct led_ops *ops = led_get_ops(dev);
@@ -81,6 +95,20 @@ int led_set_period(struct udevice *dev, int period_ms)
return ops->set_period(dev, period_ms);
}
+
+int led_set_period_by_label(const char *label, int period_ms)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = led_get_by_label(label, &dev);
+ if (ret) {
+ printf("Failed to get LED by label %s\n", label);
+ return ret;
+ }
+
+ return led_set_period(dev, period_ms);
+}
#endif
static int led_post_bind(struct udevice *dev)
diff --git a/include/led.h b/include/led.h
index a6353166289..71dd7a28d93 100644
--- a/include/led.h
+++ b/include/led.h
@@ -93,6 +93,15 @@ int led_get_by_label(const char *label, struct udevice
**devp);
*/
int led_set_state(struct udevice *dev, enum led_state_t state);
+/**
+ * led_set_state_by_label - set the state of an LED referenced by Label
+ *
+ * @label: LED label
+ * @state: LED state to set
+ * Return: 0 if OK, -ve on error
+ */
+int led_set_state_by_label(const char *label, enum led_state_t state);
+
/**
* led_get_state() - get the state of an LED
*
@@ -110,6 +119,15 @@ enum led_state_t led_get_state(struct udevice *dev);
*/
int led_set_period(struct udevice *dev, int period_ms);
+/**
+ * led_set_period_by_label - set the blink period of an LED referenced by Label
+ *
+ * @label: LED label
+ * @period_ms: LED blink period in milliseconds
+ * Return: 0 if OK, -ve on error
+ */
+int led_set_period_by_label(const char *label, int period_ms);
+
/**
* led_bind_generic() - bind children of parent to given driver
*
--
2.45.1
[PATCH 1/9] led: led_gpio: add support for SW Blink
Add support for GPIO-connected LEDs to make use of Cyclic API to
simulate Blink by software.
A new Kconfig is introduced to enable this, CONFIG_LED_GPIO_SW_BLINK.
Signed-off-by: Christian Marangi
---
drivers/led/Kconfig| 9 +++
drivers/led/led_gpio.c | 56 ++
2 files changed, 65 insertions(+)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 9837960198d..13d6eb40cea 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -91,6 +91,15 @@ config LED_GPIO
The GPIO driver must used driver model. LEDs are configured using
the device tree.
+config LED_GPIO_SW_BLINK
+ bool "LED support for GPIO software blink"
+ depends on LED_GPIO
+ select CYCLIC
+ select LED_BLINK
+ help
+ Enable support for GPIO-connected LEDs to make use of Cyclic API
+ to simulate LED blink by software.
+
config SPL_LED_GPIO
bool "LED support for GPIO-connected LEDs in SPL"
depends on SPL_LED && SPL_DM_GPIO
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index ce22fb49f2a..20a6c149e4a 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -4,6 +4,7 @@
* Written by Simon Glass
*/
+#include
#include
#include
#include
@@ -13,13 +14,60 @@
struct led_gpio_priv {
struct gpio_desc gpio;
+#ifdef CONFIG_LED_GPIO_SW_BLINK
+ bool sw_blink;
+ struct cyclic_info cyclic;
+#endif
};
+#ifdef CONFIG_LED_GPIO_SW_BLINK
+static void gpio_led_toggle(struct cyclic_info *ctx)
+{
+ struct led_gpio_priv *priv = container_of(ctx, struct led_gpio_priv,
cyclic);
+ struct gpio_desc *gpio = &priv->gpio;
+ int state;
+
+ state = dm_gpio_get_value(gpio);
+ if (state < 0) {
+ printf("Error getting value for GPIO %d\n",
+ gpio->offset);
+ return;
+ }
+
+ dm_gpio_set_value(gpio, !state);
+}
+
+static int gpio_led_set_period(struct udevice *dev, int period_ms)
+{
+ struct led_gpio_priv *priv = dev_get_priv(dev);
+ char cyclic_name[16];
+
+ if (priv->sw_blink)
+ cyclic_unregister(&priv->cyclic);
+
+ snprintf(cyclic_name, sizeof(cyclic_name),
+"gpio_cyclic%u", priv->gpio.offset);
+ cyclic_register(&priv->cyclic, gpio_led_toggle,
+ period_ms * 500, cyclic_name);
+
+ /* Init the LED on */
+ dm_gpio_set_value(&priv->gpio, LEDST_ON);
+
+ priv->sw_blink = true;
+ return 0;
+}
+#endif
+
static int gpio_led_set_state(struct udevice *dev, enum led_state_t state)
{
struct led_gpio_priv *priv = dev_get_priv(dev);
int ret;
+#ifdef CONFIG_LED_GPIO_SW_BLINK
+ if (priv->sw_blink)
+ cyclic_unregister(&priv->cyclic);
+#endif
+
if (!dm_gpio_is_valid(&priv->gpio))
return -EREMOTEIO;
switch (state) {
@@ -50,6 +98,11 @@ static enum led_state_t gpio_led_get_state(struct udevice
*dev)
if (ret < 0)
return ret;
+#ifdef CONFIG_LED_GPIO_SW_BLINK
+ if (priv->sw_blink)
+ return LEDST_BLINK;
+#endif
+
return ret ? LEDST_ON : LEDST_OFF;
}
@@ -84,6 +137,9 @@ static int led_gpio_bind(struct udevice *parent)
static const struct led_ops gpio_led_ops = {
.set_state = gpio_led_set_state,
.get_state = gpio_led_get_state,
+#ifdef CONFIG_LED_GPIO_SW_BLINK
+ .set_period = gpio_led_set_period,
+#endif
};
U_BOOT_DRIVER(led_gpio) = {
--
2.45.1
[PATCH 0/9] led: introduce LED boot and activity function
This series is a reworked version of the previous seried: misc: introduce STATUS LED activity function This series port and expand the legacy concept of LED boot from the legacy Status LED API to new LED API. One thing that many device need is a way to communicate to the user that the device is actually doing something. This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover. There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on. A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink. To fix this and handle the problem of device not supporting HW blink, expand the GPIO LED framework with support for SW blink with the new Kconfig. Additional Kconfg are also introduced to set the LED boot and activity. Those are referenced by label. A documentation for old and these new LED API is created. (world tested with the azure pipeline) Christian Marangi (9): led: led_gpio: add support for SW Blink led: implement led_set_state/paeriod_by_label led: implement LED boot API common: board_r: rework BOOT LED handling led: implement LED activity API tftp: implement support for LED activity mtd: implement support for LED activity ubi: implement support for LED activity doc: introduce led.rst documentation cmd/mtd.c| 19 ++ cmd/ubi.c| 15 - common/board_r.c | 25 ++- doc/api/index.rst| 1 + doc/api/led.rst | 10 +++ drivers/led/Kconfig | 54 drivers/led/led-uclass.c | 28 drivers/led/led_gpio.c | 56 include/led.h| 136 +++ net/tftp.c | 7 ++ 10 files changed, 347 insertions(+), 4 deletions(-) create mode 100644 doc/api/led.rst -- 2.45.1
Re: [GIT PULL] Please pull u-boot-imx-next-20240624
On Mon, Jun 24, 2024 at 10:35:53AM -0300, Fabio Estevam wrote: > Hi Tom, > > Please pull from u-boot-imx/next, thanks. > > The following changes since commit 81e2b69880566a90e909a7e2c02dff0c39a8c1e5: > > Merge patch series "boot: fix crash in bootflow menu with EFI BOOTMGR > support + typos" (2024-06-20 11:41:43 -0600) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-next-20240624 > > for you to fetch changes up to b7f677dc40429a8172c7ba5edcf3b426097e2881: > > ARM: imx: Enable SPL DTO application support for i.MX8MP DHCOM PDK2 > (2024-06-24 09:24:16 -0300) > > u-boot-imx-next-20240624 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: beagle: beagleplay: enable OF_SYSTEM_SETUP
On Wed, 19 Jun 2024 14:12:30 -0500, Bryan Brattlof wrote: > Unfortunately when enabling FDT fixups for the AM62x family of SoCs and > moving TF-A to the bottom of RAM we missed the BeaglePlay. This is > causing Linux's memory allocator to clobber TF-A and break its boot. > > Enable OF_SYSTEM_SETUP to fixup the kernel's FDT to inform it of the > actual location of the firmware > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v2 0/5] FUSB302 USB-C controller support
On Tue, Jun 4, 2024 at 9:35 AM Sebastian Reichel wrote: > > Hi, > > On ROCK 5B power is usually supplied via it's USB-C port. This port has the > data lines connected to RK3588, VBUS connected to the input regulator and > CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be > accessed via I2C from RK3588. The USB-C controller is needed to figure out > the USB-C cable orientation, but also to do USB PD communication. Thus it > would be great to enable support for it in the operating system. > > But the USB-PD specification requires, that a device reacts to USB-PD messages > send by the power-supply within around 5 seconds. If that does not happen the > power-supply assumes, that the device does not support USB-PD. If a device > later starts sending USB-PD messages it is considered an error, which is > solved > by doing a hard reset. A USB-PD hard reset means, that all supply voltages are > removed for a short period of time. For boards, which are solely powered > through their USB-C port, like the Radxa Rock 5B, this results in an machine > reset. This is currently worked around by not describing the FUSB302 in the > kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means > > 1. the USB-C port cannot be used at all > 2. the board will be running via fallback supply, which provides limited >power capabilities > > In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so > that we react to the power-supply's queries in time. The code, which is > originally from the Linux kernel, consists of two parts: > > 1. the tcpm state machine, which implements the Type C port manager state >machine as described in the USB PD specification > 2. the fusb302 driver, which knows about specific registers > > Especially the first part has been heavily modified compared to the > kernel, which makes use of multiple delayed works and threads. For this > I used a priorly ported version from Rockchip, removed their hacks and > any states not necessary in U-Boot (e.g. audio accessory support). > Hi Sebastian, It seems here that your goal was primarily to react to the USB-PD messages to negotiate board power. It looks like your tpmc class implementation has the ability to handle role determination among everything else from the tpmc but it's not clear to me how a tpmc would hook into a USB controller to provide role feedback. The rk3588 you're using in this series has a DWC3 controller configured with dr_mode of otg which means it will register the dwc3-generic-peripheral driver. When dwc3_core_init_mode is called, what exists to set dwc->dr_mode according to the mode the TPMC is showing? In other words what is here to provide the means for your OTG controller to act in both host mode and device mode? Perhaps it is beyond the scope of your series but I'm looking for a framework where a driver monitoring a GPIO can provide the role to UDC drivers. For example, I'm talking about a USB-B connector with the ID pin going to a generic GPIO or a GPIO connected to a bus-less type-C CC controller like the TPS25821 which provides a SINK# pin to specify if you have a host cable vs a device cable attached. Best Regards, Tim
[PATCH] pci_ids: fix i225 unprogrammed value
This patch fixes the I225 hardware default value at 0x15FD meaning empty flash image or the NVM configuration loading failed Signed-off-by: Marjolaine Amate --- include/pci_ids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/pci_ids.h b/include/pci_ids.h index f1886c3a75..b2136d3e9d 100644 --- a/include/pci_ids.h +++ b/include/pci_ids.h @@ -2710,7 +2710,7 @@ #define PCI_DEVICE_ID_INTEL_I211_COPPER0x1539 #define PCI_DEVICE_ID_INTEL_I210_COPPER_FLASHLESS 0x157b #define PCI_DEVICE_ID_INTEL_I210_SERDES_FLASHLESS 0x157c -#define PCI_DEVICE_ID_INTEL_I225_UNPROGRAMMED 0x15dF +#define PCI_DEVICE_ID_INTEL_I225_UNPROGRAMMED 0x15fd #define PCI_DEVICE_ID_INTEL_I225_IT0x0d9f #define PCI_DEVICE_ID_INTEL_80960_RP 0x1960 #define PCI_DEVICE_ID_INTEL_82840_HB 0x1a21 -- 2.43.0
[PATCH v2 1/2] imx: hab: rename imx_sec_config_fuse_t to imx_fuse_t
The imx_sec_config_fuse_t structure is not specific to the sec_config
fuse, but can be used for all fuse words.
Rename the structure to a more generic name to be reused for other
fuses.
Signed-off-by: Paul Geurts
---
arch/arm/include/asm/mach-imx/hab.h | 4 ++--
arch/arm/mach-imx/hab.c | 4 ++--
arch/arm/mach-imx/imx8m/soc.c | 2 +-
arch/arm/mach-imx/mx6/soc.c | 2 +-
arch/arm/mach-imx/mx7/soc.c | 2 +-
arch/arm/mach-imx/mx7ulp/soc.c | 2 +-
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/mach-imx/hab.h
b/arch/arm/include/asm/mach-imx/hab.h
index 2abf28ea45bc..52cd8aff87e1 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -132,13 +132,13 @@ enum hab_target {
HAB_TGT_ANY = 0x55,
};
-struct imx_sec_config_fuse_t {
+struct imx_fuse_t {
int bank;
int word;
};
#if defined(CONFIG_IMX_HAB)
-extern struct imx_sec_config_fuse_t const imx_sec_config_fuse;
+extern struct imx_fuse_t const imx_sec_config_fuse;
#endif
/*Function prototype description*/
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 27e053ef701c..1de0b648efdb 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -871,8 +871,8 @@ static int validate_ivt(struct ivt *ivt_initial)
bool imx_hab_is_enabled(void)
{
- struct imx_sec_config_fuse_t *fuse =
- (struct imx_sec_config_fuse_t *)&imx_sec_config_fuse;
+ struct imx_fuse_t *fuse =
+ (struct imx_fuse_t *)&imx_sec_config_fuse;
uint32_t reg;
int ret;
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 0c49fb9cd488..89e77236f024 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -36,7 +36,7 @@
DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_IMX_HAB)
-struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
+struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 1,
.word = 3,
};
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index c2875e727c94..703f2b3093dc 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -52,7 +52,7 @@ U_BOOT_DRVINFO(imx6_thermal) = {
#endif
#if defined(CONFIG_IMX_HAB)
-struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
+struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 0,
.word = 6,
};
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 689dbefe8ee0..f95c7845cf06 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -128,7 +128,7 @@ static void isolate_resource(void)
#endif
#if defined(CONFIG_IMX_HAB)
-struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
+struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 1,
.word = 3,
};
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 217b7c45867d..e0b17e1b4ff1 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -38,7 +38,7 @@
static char *get_reset_cause(char *);
#if defined(CONFIG_IMX_HAB)
-struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
+struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 29,
.word = 6,
};
--
2.30.2
[PATCH v2 2/2] imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
The decision on whether HAB is enabled is solely based on the SEC_CONFIG
fuse. The HAB FIELD_RETURN feature is able to permanently disable HAB on
a CPU, after which it is able to boot unsigned firmware. U-Boot however
does not take into account the FIELD_RETURN mode, and refuses to boot
unsigned software when the feature is enabled.
Also take the FIELD_RETURN fuse into account when deciding whether HAB
is enabled. When The FIELD_RETURN fuse is blown, HAB is not enabled.
Tested on i.MX8M Mini, i.MX8M Plus, i.MX8M Nano and i.MX6ULL
Signed-off-by: Paul Geurts
---
arch/arm/include/asm/mach-imx/hab.h | 1 +
arch/arm/mach-imx/hab.c | 19 ---
arch/arm/mach-imx/imx8m/soc.c | 5 +
arch/arm/mach-imx/mx6/soc.c | 5 +
arch/arm/mach-imx/mx7/soc.c | 5 +
arch/arm/mach-imx/mx7ulp/soc.c | 5 +
6 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/mach-imx/hab.h
b/arch/arm/include/asm/mach-imx/hab.h
index 52cd8aff87e1..d70e8eac1358 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -139,6 +139,7 @@ struct imx_fuse_t {
#if defined(CONFIG_IMX_HAB)
extern struct imx_fuse_t const imx_sec_config_fuse;
+extern struct imx_fuse_t const imx_field_return_fuse;
#endif
/*Function prototype description*/
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 1de0b648efdb..03d827e6c1eb 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -27,6 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define IS_HAB_ENABLED_BIT \
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
((is_soc_type(MXC_SOC_MX7) || is_soc_type(MXC_SOC_IMX8M)) ? 0x200
: 0x2))
+#define IS_FIELD_RETURN_BIT 0x0001
#ifdef CONFIG_MX7ULP
#define HAB_M4_PERSISTENT_START((soc_rev() >= CHIP_REV_2_0) ?
0x20008040 : \
@@ -871,18 +872,30 @@ static int validate_ivt(struct ivt *ivt_initial)
bool imx_hab_is_enabled(void)
{
- struct imx_fuse_t *fuse =
+ struct imx_fuse_t *sec_config =
(struct imx_fuse_t *)&imx_sec_config_fuse;
+ struct imx_fuse_t *field_return =
+ (struct imx_fuse_t *)&imx_field_return_fuse;
uint32_t reg;
+ bool is_enabled;
int ret;
- ret = fuse_read(fuse->bank, fuse->word, ®);
+ ret = fuse_read(sec_config->bank, sec_config->word, ®);
if (ret) {
puts("\nSecure boot fuse read error\n");
return ret;
}
+ is_enabled = (reg & IS_HAB_ENABLED_BIT) == IS_HAB_ENABLED_BIT;
+ if (is_enabled) {
+ ret = fuse_read(field_return->bank, field_return->word, ®);
+ if (ret) {
+ puts("\nField return fuse read error\n");
+ return ret;
+ }
+ is_enabled = !(reg & IS_FIELD_RETURN_BIT);
+ }
- return (reg & IS_HAB_ENABLED_BIT) == IS_HAB_ENABLED_BIT;
+ return is_enabled;
}
int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 89e77236f024..af0844946378 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -40,6 +40,11 @@ struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 1,
.word = 3,
};
+
+struct imx_fuse_t const imx_field_return_fuse = {
+ .bank = 8,
+ .word = 3,
+};
#endif
int timer_init(void)
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 703f2b3093dc..02179b02b8d2 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -56,6 +56,11 @@ struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 0,
.word = 6,
};
+
+struct imx_fuse_t const imx_field_return_fuse = {
+ .bank = 5,
+ .word = 6,
+};
#endif
u32 get_nr_cpus(void)
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index f95c7845cf06..3369696e4614 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -132,6 +132,11 @@ struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 1,
.word = 3,
};
+
+struct imx_fuse_t const imx_field_return_fuse = {
+ .bank = 8,
+ .word = 3,
+};
#endif
static bool is_mx7d(void)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index e0b17e1b4ff1..d11204cb2479 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -42,6 +42,11 @@ struct imx_fuse_t const imx_sec_config_fuse = {
.bank = 29,
.word = 6,
};
+
+struct imx_fuse_t const imx_field_return_fuse = {
+ .bank = 9,
+ .word = 6,
+};
#endif
#define ROM_VERSION_ADDR 0x80
--
2.30.2
[PATCH v2 0/2] imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
The imx_hab_is_enabled function makes sure SPL and U-Boot only blocks the boot process when HAB is actually enabled. Currently only the SEC_CONFIG fuse is checked for this, as this is the fuse that closes the board for HAB. The Field return fuse however is used to permanently disable HAB. This fuse is not taken into account. Take the FIELD_RETURN fuse into account as well when deciding whether HAB is enabled. v2: - Split up into two commits
[PATCH] e1000: add support for i226
This patch adds support for Intel Foxville I226
devices LM,V,I,K in e1000 driver.
Signed-off-by: Marjolaine Amate
---
drivers/net/e1000.c | 18 ++
drivers/net/e1000.h | 2 ++
include/pci_ids.h | 7 +++
3 files changed, 27 insertions(+)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 4e7ba66677..f9803b92b0 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -108,6 +108,12 @@ static struct pci_device_id e1000_supported[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_80003ES2LAN_SERDES_DPT) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_80003ES2LAN_COPPER_SPT) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_80003ES2LAN_SERDES_SPT) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I226_K) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I226_LMVP) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I226_LM) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I226_V) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I226_IT) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_I226_UNPROGRAMMED) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_I210_UNPROGRAMMED) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_I211_UNPROGRAMMED) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I210_COPPER) },
@@ -1569,6 +1575,12 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_ICH8_IGP_M:
hw->mac_type = e1000_ich8lan;
break;
+ case PCI_DEVICE_ID_INTEL_I226_K:
+ case PCI_DEVICE_ID_INTEL_I226_LMVP:
+ case PCI_DEVICE_ID_INTEL_I226_LM:
+ case PCI_DEVICE_ID_INTEL_I226_V:
+ case PCI_DEVICE_ID_INTEL_I226_IT:
+ case PCI_DEVICE_ID_INTEL_I226_UNPROGRAMMED:
case PCI_DEVICE_ID_INTEL_I210_UNPROGRAMMED:
case PCI_DEVICE_ID_INTEL_I211_UNPROGRAMMED:
case PCI_DEVICE_ID_INTEL_I210_COPPER:
@@ -4843,6 +4855,8 @@ static int e1000_set_phy_type (struct e1000_hw *hw)
hw->phy_type = e1000_phy_igb;
break;
case I225_I_PHY_ID:
+ case I226_LM_PHY_ID:
+ case I226_I_PHY_ID:
hw->phy_type = e1000_phy_igc;
break;
/* Fall Through */
@@ -4954,6 +4968,10 @@ e1000_detect_gig_phy(struct e1000_hw *hw)
match = true;
if (hw->phy_id == I225_I_PHY_ID)
match = true;
+ if (hw->phy_id == I226_LM_PHY_ID)
+ match = true;
+ if (hw->phy_id == I226_I_PHY_ID)
+ match = true;
break;
default:
DEBUGOUT("Invalid MAC type %d\n", hw->mac_type);
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index e1311126a3..aa649328f5 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -2421,7 +2421,9 @@ struct e1000_hw {
#define BME1000_E_PHY_ID 0x01410CB0
#define I210_I_PHY_ID 0x01410C00
+#define I226_LM_PHY_ID 0x67C9DC10
#define I225_I_PHY_ID 0x67C9DCC0
+#define I226_I_PHY_ID 0x67C9DCD0
/* Miscellaneous PHY bit definitions. */
#define PHY_PREAMBLE 0x
diff --git a/include/pci_ids.h b/include/pci_ids.h
index f1886c3a75..834ec926b5 100644
--- a/include/pci_ids.h
+++ b/include/pci_ids.h
@@ -2701,6 +2701,11 @@
#define PCI_DEVICE_ID_INTEL_82441 0x1237
#define PCI_DEVICE_ID_INTEL_82380FB0x124b
#define PCI_DEVICE_ID_INTEL_82439 0x1250
+#define PCI_DEVICE_ID_INTEL_I226_LM0x125b
+#define PCI_DEVICE_ID_INTEL_I226_V 0x125c
+#define PCI_DEVICE_ID_INTEL_I226_IT0x125d
+#define PCI_DEVICE_ID_INTEL_I221_V 0x125e
+#define PCI_DEVICE_ID_INTEL_I226_UNPROGRAMMED 0x125f
#define PCI_DEVICE_ID_INTEL_I210_UNPROGRAMMED 0x1531
#define PCI_DEVICE_ID_INTEL_I211_UNPROGRAMMED 0x1532
#define PCI_DEVICE_ID_INTEL_I210_COPPER0x1533
@@ -2930,6 +2935,7 @@
#define PCI_DEVICE_ID_INTEL_LYNNFIELD_MC_CH2_ADDR_REV2 0x2db1
#define PCI_DEVICE_ID_INTEL_LYNNFIELD_MC_CH2_RANK_REV2 0x2db2
#define PCI_DEVICE_ID_INTEL_LYNNFIELD_MC_CH2_TC_REV20x2db3
+#define PCI_DEVICE_ID_INTEL_I226_K 0x3102
#define PCI_DEVICE_ID_INTEL_82855PM_HB 0x3340
#define PCI_DEVICE_ID_INTEL_IOAT_TBG4 0x3429
#define PCI_DEVICE_ID_INTEL_IOAT_TBG5 0x342a
@@ -3001,6 +3007,7 @@
#define PCI_DEVICE_ID_INTEL_UNC_R3QPI1 0x3c45
#define PCI_DEVICE_ID_INTEL_JAKETOWN_UBOX 0x3ce0
#define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
+#define PCI_DEVICE_ID_INTEL_I226_LMVP 0x5503
#define PCI_DEVICE_ID_INTEL_5100_160x65f0
#define PCI_DEVICE_ID_INTEL_5100_190x65f3
#define PCI_DEVICE_ID_INTEL_5100_210x65f5
--
2.43.0
[PATCH v4 14/14] clk: mediatek: mt7986: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7986-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7986.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7986.c
b/drivers/clk/mediatek/clk-mt7986.c
index b3fa63fc0ab..efc3d4120b7 100644
--- a/drivers/clk/mediatek/clk-mt7986.c
+++ b/drivers/clk/mediatek/clk-mt7986.c
@@ -533,6 +533,7 @@ static const struct mtk_clk_tree mt7986_infracfg_clk_tree =
{
static const struct udevice_id mt7986_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7986-fixed-plls" },
+ { .compatible = "mediatek,mt7986-apmixedsys" },
{}
};
--
2.45.1
[PATCH v4 13/14] clk: mediatek: mt7988: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7988-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7988.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7988.c
b/drivers/clk/mediatek/clk-mt7988.c
index 34e7b2d734c..32b04511781 100644
--- a/drivers/clk/mediatek/clk-mt7988.c
+++ b/drivers/clk/mediatek/clk-mt7988.c
@@ -833,6 +833,7 @@ static const struct mtk_clk_tree mt7988_infracfg_clk_tree =
{
static const struct udevice_id mt7988_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7988-fixed-plls" },
+ { .compatible = "mediatek,mt7988-apmixedsys" },
{}
};
--
2.45.1
[PATCH v4 12/14] pci: mediatek: make pcie-phy optional for gen3
Set pcie-phy optional for PCIe gen3. MT7988 doesn't require it and
making it mandatory prevent the driver to correctly probe.
Signed-off-by: Christian Marangi
---
drivers/pci/pcie_mediatek_gen3.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pcie_mediatek_gen3.c b/drivers/pci/pcie_mediatek_gen3.c
index 673813b8b75..0149edae0bf 100644
--- a/drivers/pci/pcie_mediatek_gen3.c
+++ b/drivers/pci/pcie_mediatek_gen3.c
@@ -284,9 +284,8 @@ static int mtk_pcie_power_on(struct udevice *dev)
pcie->priv = dev;
- err = generic_phy_get_by_name(dev, "pcie-phy", &pcie->phy);
- if (err)
- return err;
+ /* pcie-phy is optional (mt7988 doesn't need it) */
+ generic_phy_get_by_name(dev, "pcie-phy", &pcie->phy);
/*
* Upstream linux kernel devine these clock without clock-names
@@ -308,13 +307,15 @@ static int mtk_pcie_power_on(struct udevice *dev)
if (err)
return err;
- err = generic_phy_init(&pcie->phy);
- if (err)
- return err;
+ if (pcie->phy.dev) {
+ err = generic_phy_init(&pcie->phy);
+ if (err)
+ return err;
- err = generic_phy_power_on(&pcie->phy);
- if (err)
- goto err_phy_on;
+ err = generic_phy_power_on(&pcie->phy);
+ if (err)
+ goto err_phy_on;
+ }
err = clk_enable(&pcie->pl_250m_ck);
if (err)
@@ -348,7 +349,8 @@ err_clk_tl_26m:
err_clk_pl_250m:
clk_disable(&pcie->pl_250m_ck);
err_phy_on:
- generic_phy_exit(&pcie->phy);
+ if (pcie->phy.dev)
+ generic_phy_exit(&pcie->phy);
return err;
}
--
2.45.1
[PATCH v4 11/14] pinctrl: mediatek: mt7981: init device before relocation
Upstream kernel linux define pinctrl for uart0, hence this pin group
and pinctrl driver is needed before relocation. Add DM_FLAG_PRE_RELOC
flag to init and mute mtk_serial error on early serial init.
Signed-off-by: Christian Marangi
---
drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7981.c
b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
index 3fa198ed79c..4bc4abe6518 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7981.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
@@ -1050,4 +1050,5 @@ U_BOOT_DRIVER(mt7981_pinctrl) = {
.ops = &mtk_pinctrl_ops,
.probe = mtk_pinctrl_mt7981_probe,
.priv_auto = sizeof(struct mtk_pinctrl_priv),
+ .flags = DM_FLAG_PRE_RELOC,
};
--
2.45.1
[PATCH v4 10/14] pinctrl: mediatek: add support for gpio-controller property in root node
Add support for gpio-controller property in root pinctrl node.
This is to follow upstream linux DTSI that doesn't define the
gpio-controller and cells in dedicated nodes.
Signed-off-by: Christian Marangi
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 37fc28bb779..ede3959c94f 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -761,6 +761,15 @@ static int mtk_gpiochip_register(struct udevice *parent)
if (!drv)
return -ENOENT;
+ /*
+* Support upstream linux DTSI that define gpio-controller
+* in the root node (instead of a dedicated subnode)
+*/
+ if (dev_read_bool(parent, "gpio-controller")) {
+ node = dev_ofnode(parent);
+ goto bind;
+ }
+
ret = -ENOENT;
dev_for_each_subnode(node, parent)
if (ofnode_read_bool(node, "gpio-controller")) {
@@ -771,6 +780,7 @@ static int mtk_gpiochip_register(struct udevice *parent)
if (ret)
return ret;
+bind:
ret = device_bind_with_driver_data(parent, &mtk_gpio_driver,
"mediatek_gpio", 0, node,
&dev);
--
2.45.1
[PATCH v4 09/14] clk: mediatek: mt7981: support alternative compatible for fixed-plls
Support alternative compatible for fixed-plls clocks used upstream with
the compatible mediatek,mt7981-apmixedsys.
Signed-off-by: Christian Marangi
---
drivers/clk/mediatek/clk-mt7981.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/mediatek/clk-mt7981.c
b/drivers/clk/mediatek/clk-mt7981.c
index 7fcb81419cd..13dc3df0e9e 100644
--- a/drivers/clk/mediatek/clk-mt7981.c
+++ b/drivers/clk/mediatek/clk-mt7981.c
@@ -543,6 +543,7 @@ static const struct mtk_clk_tree mt7981_infracfg_clk_tree =
{
static const struct udevice_id mt7981_fixed_pll_compat[] = {
{ .compatible = "mediatek,mt7981-fixed-plls" },
+ { .compatible = "mediatek,mt7981-apmixedsys" },
{}
};
--
2.45.1
[PATCH v4 08/14] mmc: mediatek: add support for upstream linux clock and property
Add support for upstream linux clock and map U-Boot property to the one
use in upstream linux where supported.
Also add handling for the use_internal_cd that on upstream is hardcoded
enabled on mt7620.
Signed-off-by: Christian Marangi
---
drivers/mmc/mtk-sd.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index 3a9258255a7..ebd72178b59 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -335,6 +335,7 @@ struct msdc_compatible {
bool enhance_rx;
bool builtin_pad_ctrl;
bool default_pad_dly;
+ bool use_internal_cd;
};
struct msdc_delay_phase {
@@ -365,6 +366,10 @@ struct msdc_host {
struct clk src_clk_cg; /* optional, MSDC source clock control gate */
struct clk h_clk; /* MSDC core clock */
+ /* upstream linux clock */
+ struct clk axi_cg_clk; /* optional, AXI clock */
+ struct clk ahb_cg_clk; /* optional, AHB clock */
+
u32 src_clk_freq; /* source clock */
u32 mclk; /* mmc framework required bus clock */
u32 sclk; /* actual calculated bus clock */
@@ -1637,6 +1642,11 @@ static void msdc_ungate_clock(struct msdc_host *host)
clk_enable(&host->h_clk);
if (host->src_clk_cg.dev)
clk_enable(&host->src_clk_cg);
+
+ if (host->axi_cg_clk.dev)
+ clk_enable(&host->axi_cg_clk);
+ if (host->ahb_cg_clk.dev)
+ clk_enable(&host->ahb_cg_clk);
}
static int msdc_drv_probe(struct udevice *dev)
@@ -1650,6 +1660,9 @@ static int msdc_drv_probe(struct udevice *dev)
host->dev_comp = (struct msdc_compatible *)dev_get_driver_data(dev);
+ if (host->dev_comp->use_internal_cd)
+ host->builtin_cd = 1;
+
host->src_clk_freq = clk_get_rate(&host->src_clk);
if (host->dev_comp->clk_div_bits == 8)
@@ -1715,18 +1728,31 @@ static int msdc_of_to_plat(struct udevice *dev)
clk_get_by_name(dev, "source_cg", &host->src_clk_cg); /* optional */
+ /* upstream linux clock */
+ clk_get_by_name(dev, "axi_cg", &host->axi_cg_clk); /* optional */
+ clk_get_by_name(dev, "ahb_cg", &host->ahb_cg_clk); /* optional */
+
#if CONFIG_IS_ENABLED(DM_GPIO)
gpio_request_by_name(dev, "wp-gpios", 0, &host->gpio_wp, GPIOD_IS_IN);
gpio_request_by_name(dev, "cd-gpios", 0, &host->gpio_cd, GPIOD_IS_IN);
#endif
host->hs400_ds_delay = dev_read_u32_default(dev, "hs400-ds-delay", 0);
- host->hs200_cmd_int_delay =
- dev_read_u32_default(dev, "cmd_int_delay", 0);
+ if (dev_read_u32(dev, "mediatek,hs200-cmd-int-delay",
+&host->hs200_cmd_int_delay))
+ host->hs200_cmd_int_delay =
+ dev_read_u32_default(dev, "cmd_int_delay", 0);
+
host->hs200_write_int_delay =
dev_read_u32_default(dev, "write_int_delay", 0);
- host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
+
+ if (dev_read_u32(dev, "mediatek,latch-ck", &host->latch_ck))
+ host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
+
host->r_smpl = dev_read_u32_default(dev, "r_smpl", 0);
+ if (dev_read_bool(dev, "mediatek,hs400-cmd-resp-sel-rising"))
+ host->r_smpl = 1;
+
host->builtin_cd = dev_read_u32_default(dev, "builtin-cd", 0);
host->cd_active_high = dev_read_bool(dev, "cd-active-high");
@@ -1775,6 +1801,7 @@ static const struct msdc_compatible mt7620_compat = {
.enhance_rx = false,
.builtin_pad_ctrl = true,
.default_pad_dly = true,
+ .use_internal_cd = true,
};
static const struct msdc_compatible mt7621_compat = {
@@ -1805,7 +1832,7 @@ static const struct msdc_compatible mt7623_compat = {
.data_tune = true,
.busy_check = false,
.stop_clk_fix = false,
- .enhance_rx = false
+ .enhance_rx = false,
};
static const struct msdc_compatible mt7986_compat = {
--
2.45.1
[PATCH v4 07/14] serial: mediatek: add special handling for highspeed and linux compat
Upstream linux serial driver use a different logic to setup serial regs.
They have 2 interval:
- < 115200 we use lowspeed regs and 16 * baud
- >= 115200 we use highspeed
We currently use force_highspeed property to force usage of highspeed
regs even with low baud rate.
Add special handling if the upstream compatible is used where we just
apply the same interval with anything >= 115200 in highspeed simulating
force_highspeed.
Signed-off-by: Christian Marangi
---
drivers/serial/serial_mtk.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index 78e8d9dc735..becf9317076 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -80,6 +81,7 @@ struct mtk_serial_regs {
* @fixed_clk_rate:Fallback fixed baud clock rate if baud clock
* device is not specified
* @force_highspeed: Force using high-speed mode
+ * @upstream_highspeed_logic: Apply upstream high-speed logic
*/
struct mtk_serial_priv {
struct mtk_serial_regs __iomem *regs;
@@ -87,6 +89,7 @@ struct mtk_serial_priv {
struct clk clk_bus;
u32 fixed_clk_rate;
bool force_highspeed;
+ bool upstream_highspeed_logic;
};
static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud,
@@ -113,7 +116,12 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv
*priv, int baud,
goto set_baud;
}
- if (priv->force_highspeed)
+ /*
+* Upstream linux use highspeed for anything >= 115200 and lowspeed
+* for < 115200. Simulate this if we are using the upstream compatible.
+*/
+ if (priv->force_highspeed ||
+ (priv->upstream_highspeed_logic && baud >= 115200))
goto use_hs3;
if (baud <= 115200) {
@@ -259,6 +267,8 @@ static int mtk_serial_of_to_plat(struct udevice *dev)
clk_get_by_name(dev, "bus", &priv->clk_bus);
priv->force_highspeed = dev_read_bool(dev, "mediatek,force-highspeed");
+ priv->upstream_highspeed_logic =
+ device_is_compatible(dev, "mediatek,mt6577-uart");
return 0;
}
--
2.45.1
[PATCH v4 06/14] serial: mediatek: add support for bus clock and enable it
Upstream linux also provide the additional optional bus clock.
Add support for it and also enable the baud and bus clock on probe.
Signed-off-by: Christian Marangi
---
drivers/serial/serial_mtk.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index 3f569c68f22..78e8d9dc735 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -76,6 +76,7 @@ struct mtk_serial_regs {
* driver
* @regs: Register base of the serial port
* @clk: The baud clock device
+ * @clk_bus: The bus clock device
* @fixed_clk_rate:Fallback fixed baud clock rate if baud clock
* device is not specified
* @force_highspeed: Force using high-speed mode
@@ -83,6 +84,7 @@ struct mtk_serial_regs {
struct mtk_serial_priv {
struct mtk_serial_regs __iomem *regs;
struct clk clk;
+ struct clk clk_bus;
u32 fixed_clk_rate;
bool force_highspeed;
};
@@ -220,6 +222,10 @@ static int mtk_serial_probe(struct udevice *dev)
writel(UART_MCRVAL, &priv->regs->mcr);
writel(UART_FCRVAL, &priv->regs->fcr);
+ clk_enable(&priv->clk);
+ if (priv->clk_bus.dev)
+ clk_enable(&priv->clk_bus);
+
return 0;
}
@@ -250,6 +256,8 @@ static int mtk_serial_of_to_plat(struct udevice *dev)
}
}
+ clk_get_by_name(dev, "bus", &priv->clk_bus);
+
priv->force_highspeed = dev_read_bool(dev, "mediatek,force-highspeed");
return 0;
--
2.45.1
[PATCH v4 05/14] i2c: mediatek: add support for optional arb and pmic clock
Add support for optional arb and pmic clock for i2c provided in upstream
linux DTSI.
Signed-off-by: Christian Marangi
---
drivers/i2c/mtk_i2c.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/i2c/mtk_i2c.c b/drivers/i2c/mtk_i2c.c
index 5592fe91817..3450177741a 100644
--- a/drivers/i2c/mtk_i2c.c
+++ b/drivers/i2c/mtk_i2c.c
@@ -221,6 +221,8 @@ struct mtk_i2c_priv {
void __iomem *pdmabase; /* dma base address*/
struct clk clk_main;/* main clock for i2c bus */
struct clk clk_dma; /* DMA clock for i2c via DMA */
+ struct clk clk_arb; /* DMA clock for i2c ARB */
+ struct clk clk_pmic;/* DMA clock for i2c PMIC */
const struct mtk_i2c_soc_data *soc_data; /* Compatible data for
different IC */
int op; /* operation mode */
bool zero_len; /* Only transfer slave address, no data
*/
@@ -255,6 +257,18 @@ static int mtk_i2c_clk_enable(struct mtk_i2c_priv *priv)
if (ret)
return log_msg_ret("enable clk_dma", ret);
+ if (priv->clk_arb.dev) {
+ ret = clk_enable(&priv->clk_arb);
+ if (ret)
+ return log_msg_ret("enable clk_arb", ret);
+ }
+
+ if (priv->clk_pmic.dev) {
+ ret = clk_enable(&priv->clk_pmic);
+ if (ret)
+ return log_msg_ret("enable clk_pmic", ret);
+ }
+
return 0;
}
@@ -262,6 +276,18 @@ static int mtk_i2c_clk_disable(struct mtk_i2c_priv *priv)
{
int ret;
+ if (priv->clk_pmic.dev) {
+ ret = clk_disable(&priv->clk_pmic);
+ if (ret)
+ return log_msg_ret("disable clk_pmic", ret);
+ }
+
+ if (priv->clk_arb.dev) {
+ ret = clk_disable(&priv->clk_arb);
+ if (ret)
+ return log_msg_ret("disable clk_arb", ret);
+ }
+
ret = clk_disable(&priv->clk_dma);
if (ret)
return log_msg_ret("disable clk_dma", ret);
@@ -748,6 +774,10 @@ static int mtk_i2c_of_to_plat(struct udevice *dev)
ret = clk_get_by_index(dev, 1, &priv->clk_dma);
+ /* optional i2c clock */
+ clk_get_by_name(dev, "arb", &priv->clk_arb);
+ clk_get_by_name(dev, "pmic", &priv->clk_pmic);
+
return ret;
}
--
2.45.1
[PATCH v4 04/14] net: mediatek: handle alternative name for pn_swap property
Handle alternative name for pn_swap property as upstream linux use
mediatek,pnswap.
Signed-off-by: Christian Marangi
---
drivers/net/mtk_eth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index 94f17a97fe0..5098afef8a8 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -1964,7 +1964,9 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
return -ENODEV;
}
- priv->pn_swap = ofnode_read_bool(args.node, "pn_swap");
+ /* Upstream linux use mediatek,pnswap instead of pn_swap */
+ priv->pn_swap = ofnode_read_bool(args.node, "pn_swap") ||
+ ofnode_read_bool(args.node, "mediatek,pnswap");
} else if (priv->phy_interface == PHY_INTERFACE_MODE_USXGMII) {
/* get corresponding usxgmii phandle */
ret = dev_read_phandle_with_args(dev, "mediatek,usxgmiisys",
--
2.45.1
[PATCH v4 03/14] spi: mtk_spim: add support for upstream mediatek, spi-ipm compatible
Upstream kernel linux use a different compatible mediatek,spi-ipm.
Add support for this compatible and add handling for the additional
clock similar to how it's done by the upstream driver and handling for
all the property enabled by default.
Signed-off-by: Christian Marangi
---
drivers/spi/mtk_spim.c | 45 --
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/mtk_spim.c b/drivers/spi/mtk_spim.c
index 90f4c3cecb9..b360eca2b91 100644
--- a/drivers/spi/mtk_spim.c
+++ b/drivers/spi/mtk_spim.c
@@ -137,6 +137,8 @@ struct mtk_spim_capability {
* @state: Controller state
* @sel_clk: Pad clock
* @spi_clk: Core clock
+ * @parent_clk:Parent clock (needed for mediatek,spi-ipm,
upstream DTSI)
+ * @hclk: HCLK clock (needed for mediatek,spi-ipm, upstream DTSI)
* @pll_clk_rate: Controller's PLL source clock rate, which is different
* from SPI bus clock rate
* @xfer_len: Current length of data for transfer
@@ -151,6 +153,7 @@ struct mtk_spim_priv {
void __iomem *base;
u32 state;
struct clk sel_clk, spi_clk;
+ struct clk parent_clk, hclk;
u32 pll_clk_rate;
u32 xfer_len;
struct mtk_spim_capability hw_cap;
@@ -650,7 +653,21 @@ static int mtk_spim_probe(struct udevice *dev)
if (!priv->base)
return -EINVAL;
- mtk_spim_get_attr(priv, dev);
+ /*
+* Upstream linux driver for ipm design enable all the modes
+* and setup the calibrarion values directly in the driver with
+* standard values.
+*/
+ if (device_is_compatible(dev, "mediatek,spi-ipm")) {
+ priv->hw_cap.enhance_timing = true;
+ priv->hw_cap.dma_ext = true;
+ priv->hw_cap.ipm_design = true;
+ priv->hw_cap.support_quad = true;
+ priv->sample_sel = 0;
+ priv->tick_dly = 2;
+ } else {
+ mtk_spim_get_attr(priv, dev);
+ }
ret = clk_get_by_name(dev, "sel-clk", &priv->sel_clk);
if (ret < 0) {
@@ -664,8 +681,31 @@ static int mtk_spim_probe(struct udevice *dev)
return ret;
}
- clk_enable(&priv->sel_clk);
+ /*
+* Upstream DTSI use a different compatible that provide additional
+* clock instead of the assigned-clock implementation.
+*/
+ if (device_is_compatible(dev, "mediatek,spi-ipm")) {
+ ret = clk_get_by_name(dev, "parent-clk", &priv->parent_clk);
+ if (ret < 0) {
+ dev_err(dev, "failed to get parent-clk\n");
+ return ret;
+ }
+
+ ret = clk_get_by_name(dev, "hclk", &priv->hclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to get hclk\n");
+ return ret;
+ }
+
+ clk_enable(&priv->parent_clk);
+ clk_set_parent(&priv->sel_clk, &priv->parent_clk);
+
+ clk_enable(&priv->hclk);
+ }
+
clk_enable(&priv->spi_clk);
+ clk_enable(&priv->sel_clk);
priv->pll_clk_rate = clk_get_rate(&priv->spi_clk);
if (priv->pll_clk_rate == 0)
@@ -698,6 +738,7 @@ static const struct dm_spi_ops mtk_spim_ops = {
static const struct udevice_id mtk_spim_ids[] = {
{ .compatible = "mediatek,ipm-spi" },
+ { .compatible = "mediatek,spi-ipm", },
{}
};
--
2.45.1
[PATCH v4 02/14] pci: mediatek: add PCIe controller support for filogic silicon
From: John Crispin
Add MediaTek GEN3 PCIe controller support for filogic silicon.
This is adapted from the Linux version of the driver.
Signed-off-by: John Crispin
[ fix minor problems, fix checkpatch errors ]
Signed-off-by: Christian Marangi
---
drivers/pci/Kconfig | 7 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_mediatek_gen3.c | 382 +++
3 files changed, 390 insertions(+)
create mode 100644 drivers/pci/pcie_mediatek_gen3.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 8d02ab82ad9..22a56f4ca38 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -350,6 +350,13 @@ config PCIE_MEDIATEK
Say Y here if you want to enable Gen2 PCIe controller,
which could be found on MT7623 SoC family.
+config PCIE_MEDIATEK_GEN3
+ bool "MediaTek PCIe Gen3 controller"
+ depends on ARCH_MEDIATEK
+ help
+ Say Y here if you want to enable Gen3 PCIe controller,
+ which could be found on the Mediatek Filogic SoC family.
+
config PCIE_DW_MESON
bool "Amlogic Meson DesignWare based PCIe controller"
depends on ARCH_MESON
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 2927c519129..5b2d2969802 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o
obj-$(CONFIG_PCIE_DW_COMMON) += pcie_dw_common.o
obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
+obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie_mediatek_gen3.o
obj-$(CONFIG_PCIE_ROCKCHIP) += pcie_rockchip.o
obj-$(CONFIG_PCIE_DW_ROCKCHIP) += pcie_dw_rockchip.o
obj-$(CONFIG_PCIE_DW_MESON) += pcie_dw_meson.o
diff --git a/drivers/pci/pcie_mediatek_gen3.c b/drivers/pci/pcie_mediatek_gen3.c
new file mode 100644
index 000..673813b8b75
--- /dev/null
+++ b/drivers/pci/pcie_mediatek_gen3.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek PCIe host controller driver.
+ *
+ * Copyright (c) 2023 John Crispin
+ * Driver is based on u-boot gen1/2 and upstream linux gen3 code
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pci_internal.h"
+
+/* PCIe shared registers */
+#define PCIE_CFG_ADDR 0x20
+#define PCIE_CFG_DATA 0x24
+
+#define PCIE_SETTING_REG 0x80
+
+#define PCIE_PCI_IDS_1 0x9c
+#define PCIE_RC_MODE BIT(0)
+#define PCI_CLASS(class) ((class) << 8)
+
+#define PCIE_CFGNUM_REG0x140
+#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0))
+#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8))
+#define PCIE_CFG_BYTE_EN(bytes)(((bytes) << 16) & GENMASK(19,
16))
+#define PCIE_CFG_FORCE_BYTE_EN BIT(20)
+#define PCIE_CFG_OFFSET_ADDR 0x1000
+#define PCIE_CFG_HEADER(bus, devfn)(PCIE_CFG_BUS(bus) |
PCIE_CFG_DEVFN(devfn))
+
+#define PCIE_RST_CTRL_REG 0x148
+#define PCIE_MAC_RSTB BIT(0)
+#define PCIE_PHY_RSTB BIT(1)
+#define PCIE_BRG_RSTB BIT(2)
+#define PCIE_PE_RSTB BIT(3)
+
+#define PCIE_LINK_STATUS_REG 0x154
+#define PCIE_PORT_LINKUP BIT(8)
+
+#define PCIE_INT_ENABLE_REG0x180
+
+#define PCIE_MISC_CTRL_REG 0x348
+#define PCIE_DISABLE_DVFSRC_VLT_REQBIT(1)
+
+#define PCIE_TRANS_TABLE_BASE_REG 0x800
+#define PCIE_ATR_SRC_ADDR_MSB_OFFSET0x4
+#define PCIE_ATR_TRSL_ADDR_LSB_OFFSET 0x8
+#define PCIE_ATR_TRSL_ADDR_MSB_OFFSET 0xc
+#define PCIE_ATR_TRSL_PARAM_OFFSET 0x10
+#define PCIE_ATR_TLB_SET_OFFSET 0x20
+
+#define PCIE_MAX_TRANS_TABLES 8
+#define PCIE_ATR_EN BIT(0)
+#define PCIE_ATR_SIZE(size) \
+ (size) - 1) << 1) & GENMASK(6, 1)) | PCIE_ATR_EN)
+#define PCIE_ATR_ID(id) ((id) & GENMASK(3, 0))
+#define PCIE_ATR_TYPE_MEM PCIE_ATR_ID(0)
+#define PCIE_ATR_TYPE_IOPCIE_ATR_ID(1)
+#define PCIE_ATR_TLP_TYPE(type) (((type) << 16) & GENMASK(18, 16))
+#define PCIE_ATR_TLP_TYPE_MEM PCIE_ATR_TLP_TYPE(0)
+#define PCIE_ATR_TLP_TYPE_IOPCIE_ATR_TLP_TYPE(2)
+
+struct mtk_pcie {
+ void __iomem *base;
+ void *priv;
+ struct clk pl_250m_ck;
+ struct clk tl_26m_ck;
+ struct clk peri_26m_ck;
+ struct clk top_133m_ck;
+ struct reset_ctl reset_phy;
+ struct reset_ctl reset_mac;
+ struct phy phy;
+};
+
+static void mtk_pcie_config_tlp_header(const struct udevice *bus,
+ pci_dev_t devfn,
+ int where, int size)
+{
+ struct mtk_pcie *pcie = dev_get_priv(bus);
+ int bytes;
+ u32 val;
+
+ size = 1 << size;
+
[PATCH v4 01/14] phy: phy-mtk-tphy: add support for phy type switch
Add support for PHY type switch via the mediatek topmisc syscon.
This is needed on mt7981 to make the PCIe correctly work and display
LinkUp.
Follow the same implementation done on Linux kernel with the usage of
the mediatek,syscon-type property.
Example:
u3port0: usb-phy@11e10700 {
reg = <0x11e10700 0x900>;
clocks = <&topckgen CK_TOP_USB3_PHY_SEL>;
clock-names = "ref";
#phy-cells = <1>;
mediatek,syscon-type = <&topmisc 0x218 0>;
status = "okay";
};
Signed-off-by: Christian Marangi
---
drivers/phy/Kconfig| 2 +
drivers/phy/phy-mtk-tphy.c | 80 ++
2 files changed, 82 insertions(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8f767877e73..e12347e8a03 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -263,6 +263,8 @@ config PHY_MTK_TPHY
bool "MediaTek T-PHY Driver"
depends on PHY
depends on ARCH_MEDIATEK || SOC_MT7621
+ select REGMAP
+ select SYSCON
help
MediaTek T-PHY driver supports usb2.0, usb3.0 ports, PCIe and
SATA, and meanwhile supports two version T-PHY which have
diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index 6f9ac1528e8..0a45dc58629 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -215,6 +217,14 @@
#define ANA_EQ_EYE_CTRL_SIGNAL50xdc
#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
+/* PHY switch between pcie/usb3/sgmii/sata */
+#define USB_PHY_SWITCH_CTRL0x0
+#define RG_PHY_SW_TYPE GENMASK(3, 0)
+#define RG_PHY_SW_PCIE 0x0
+#define RG_PHY_SW_USB3 0x1
+#define RG_PHY_SW_SGMII0x2
+#define RG_PHY_SW_SATA 0x3
+
enum mtk_phy_version {
MTK_TPHY_V1 = 1,
MTK_TPHY_V2,
@@ -257,6 +267,10 @@ struct mtk_phy_instance {
u32 index;
u32 type;
+ struct regmap *type_sw;
+ u32 type_sw_reg;
+ u32 type_sw_index;
+
u32 eye_vrt;
u32 eye_term;
u32 discth;
@@ -616,6 +630,67 @@ static void u2_phy_props_set(struct mtk_tphy *tphy,
FIELD_PREP(PA6_RG_U2_PRE_EMP,
instance->pre_emphasis));
}
+/* type switch for usb3/pcie/sgmii/sata */
+static int phy_type_syscon_get(struct udevice *dev, struct mtk_phy_instance
*instance,
+ ofnode dn)
+{
+ struct ofnode_phandle_args args;
+ int err;
+
+ if (!ofnode_read_bool(dn, "mediatek,syscon-type"))
+ return 0;
+
+ err = ofnode_parse_phandle_with_args(dn, "mediatek,syscon-type",
+NULL, 2, 0, &args);
+ if (err)
+ return err;
+
+ instance->type_sw_reg = args.args[0];
+ instance->type_sw_index = args.args[1] & 0x3; /* <=3 */
+ instance->type_sw = syscon_node_to_regmap(args.node);
+ if (IS_ERR(instance->type_sw))
+ return PTR_ERR(instance->type_sw);
+
+ debug("phy-%s.%d: type_sw - reg %#x, index %d\n",
+ dev->name, instance->index, instance->type_sw_reg,
+ instance->type_sw_index);
+
+ return 0;
+}
+
+static int phy_type_set(struct mtk_phy_instance *instance)
+{
+ int type;
+ u32 offset;
+
+ if (!instance->type_sw)
+ return 0;
+
+ switch (instance->type) {
+ case PHY_TYPE_USB3:
+ type = RG_PHY_SW_USB3;
+ break;
+ case PHY_TYPE_PCIE:
+ type = RG_PHY_SW_PCIE;
+ break;
+ case PHY_TYPE_SGMII:
+ type = RG_PHY_SW_SGMII;
+ break;
+ case PHY_TYPE_SATA:
+ type = RG_PHY_SW_SATA;
+ break;
+ case PHY_TYPE_USB2:
+ default:
+ return 0;
+ }
+
+ offset = instance->type_sw_index * BITS_PER_BYTE;
+ regmap_update_bits(instance->type_sw, instance->type_sw_reg,
+ RG_PHY_SW_TYPE << offset, type << offset);
+
+ return 0;
+}
+
static int mtk_phy_init(struct phy *phy)
{
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
@@ -746,6 +821,7 @@ static int mtk_phy_xlate(struct phy *phy,
}
phy_parse_property(tphy, instance);
+ phy_type_set(instance);
return 0;
}
@@ -807,6 +883,10 @@ static int mtk_tphy_probe(struct udevice *dev)
&instance->da_ref_clk);
if (err)
return err;
+
+ err = phy_type_syscon_get(dev, instance, subnode);
+ if (err)
+ return err;
}
return 0;
--
2.45.1
[PATCH v4 00/14] mediatek: cumulative trivial fix for OF_UPSTREAM support
This is an initial series that have all the initial trivial fixes required for usage of OF_UPSTREAM for the mediatek SoC This also contains the pcie-gen3 driver and the required tphy support driver to make it work. Subsequent series will follow with conversion of the mtk-clk to permit usage of OF_UPSTREAM and upstream clk ID. MT7981, MT7986 and MT7988 migration to upstream clock ID is complete and working on MT7623. Series CI tested with PR [0] [0] https://github.com/u-boot/u-boot/pull/590 Changes v4: - Fix compilation error catched by Azure CI - Rework serial with legacy platform Changes v3: - Fix copy paste error in gpio-controller (dev instead of parent) - Rebase on top of next Changes v2: - Add mt7986 and mt7988 apmixed trivial PATCH - Make phy for pcie optional (it is for mt7988) - Fix broken mmc patch Christian Marangi (13): phy: phy-mtk-tphy: add support for phy type switch spi: mtk_spim: add support for upstream mediatek,spi-ipm compatible net: mediatek: handle alternative name for pn_swap property i2c: mediatek: add support for optional arb and pmic clock serial: mediatek: add support for bus clock and enable it serial: mediatek: add special handling for highspeed and linux compat mmc: mediatek: add support for upstream linux clock and property clk: mediatek: mt7981: support alternative compatible for fixed-plls pinctrl: mediatek: add support for gpio-controller property in root node pinctrl: mediatek: mt7981: init device before relocation pci: mediatek: make pcie-phy optional for gen3 clk: mediatek: mt7988: support alternative compatible for fixed-plls clk: mediatek: mt7986: support alternative compatible for fixed-plls John Crispin (1): pci: mediatek: add PCIe controller support for filogic silicon drivers/clk/mediatek/clk-mt7981.c | 1 + drivers/clk/mediatek/clk-mt7986.c | 1 + drivers/clk/mediatek/clk-mt7988.c | 1 + drivers/i2c/mtk_i2c.c | 30 ++ drivers/mmc/mtk-sd.c | 35 +- drivers/net/mtk_eth.c | 4 +- drivers/pci/Kconfig | 7 + drivers/pci/Makefile | 1 + drivers/pci/pcie_mediatek_gen3.c | 384 ++ drivers/phy/Kconfig | 2 + drivers/phy/phy-mtk-tphy.c| 80 drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 + drivers/serial/serial_mtk.c | 20 +- drivers/spi/mtk_spim.c| 45 +- 15 files changed, 614 insertions(+), 8 deletions(-) create mode 100644 drivers/pci/pcie_mediatek_gen3.c -- 2.45.1
Re: [U-BOOT-TEST][PATCH 1/1] travis-ci: SiFive Unleashed: avoid format warning
On Sun, 23 Jun 2024 12:58:15 +0200, Heinrich Schuchardt wrote: > QEMU expects the file format to be specified even for raw files. > Currently this change only suppresses a warning. > > Applied to u-boot/u-boot-test-hooks.git/master, thanks! -- Tom
[PATCH] rockchip: add support for Radxa ROCK Pi E v3.0
ROCK Pi E v3.0 uses DDR4 SDRAM instead of DDR3 SDRAM used in v1.2x.
prepare new rk3328-rock-pi-e-v3.dts in u-boot which just includes
upstream rk3328-rock-pi-e.dts.
defconfig still uses
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock-pi-e.dtb"
because v3.0 and prior are compatible.
Suggested-by: Jonas Karlman
Signed-off-by: FUKAUMI Naoki
---
...dtsi => rk3328-rock-pi-e-base-u-boot.dtsi} | 1 -
arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 47 +
arch/arm/dts/rk3328-rock-pi-e-v3-u-boot.dtsi | 4 +
arch/arm/dts/rk3328-rock-pi-e-v3.dts | 4 +
board/rockchip/evb_rk3328/MAINTAINERS | 4 +-
configs/rock-pi-e-v3-rk3328_defconfig | 97 +++
6 files changed, 111 insertions(+), 46 deletions(-)
copy arch/arm/dts/{rk3328-rock-pi-e-u-boot.dtsi =>
rk3328-rock-pi-e-base-u-boot.dtsi} (94%)
rewrite arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi (88%)
create mode 100644 arch/arm/dts/rk3328-rock-pi-e-v3-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3328-rock-pi-e-v3.dts
create mode 100644 configs/rock-pi-e-v3-rk3328_defconfig
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
b/arch/arm/dts/rk3328-rock-pi-e-base-u-boot.dtsi
similarity index 94%
copy from arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
copy to arch/arm/dts/rk3328-rock-pi-e-base-u-boot.dtsi
index d314bfad6f..39bb66c4fc 100644
--- a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock-pi-e-base-u-boot.dtsi
@@ -4,7 +4,6 @@
*/
#include "rk3328-u-boot.dtsi"
-#include "rk3328-sdram-ddr3-666.dtsi"
/ {
smbios {
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
dissimilarity index 88%
index d314bfad6f..8e82f6a6f1 100644
--- a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -1,43 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2020 Radxa
- */
-
-#include "rk3328-u-boot.dtsi"
-#include "rk3328-sdram-ddr3-666.dtsi"
-
-/ {
- smbios {
- compatible = "u-boot,sysinfo-smbios";
-
- smbios {
- system {
- manufacturer = "radxa";
- product = "rock-pi-e_rk3328";
- };
-
- baseboard {
- manufacturer = "radxa";
- product = "rock-pi-e_rk3328";
- };
-
- chassis {
- manufacturer = "radxa";
- product = "rock-pi-e_rk3328";
- };
- };
- };
-};
-
-&u2phy_host {
- phy-supply = <&vcc_host_5v>;
-};
-
-&vcc_host_5v {
- /delete-property/ regulator-always-on;
- /delete-property/ regulator-boot-on;
-};
-
-&vcc_sd {
- bootph-pre-ram;
-};
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3328-rock-pi-e-base-u-boot.dtsi"
+#include "rk3328-sdram-ddr3-666.dtsi"
diff --git a/arch/arm/dts/rk3328-rock-pi-e-v3-u-boot.dtsi
b/arch/arm/dts/rk3328-rock-pi-e-v3-u-boot.dtsi
new file mode 100644
index 00..4d89ae54e6
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e-v3-u-boot.dtsi
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3328-rock-pi-e-base-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
diff --git a/arch/arm/dts/rk3328-rock-pi-e-v3.dts
b/arch/arm/dts/rk3328-rock-pi-e-v3.dts
new file mode 100644
index 00..f1c1c36a99
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e-v3.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include "rk3328-rock-pi-e.dts"
diff --git a/board/rockchip/evb_rk3328/MAINTAINERS
b/board/rockchip/evb_rk3328/MAINTAINERS
index 675b72dd06..8f619e54e0 100644
--- a/board/rockchip/evb_rk3328/MAINTAINERS
+++ b/board/rockchip/evb_rk3328/MAINTAINERS
@@ -64,5 +64,5 @@ M: Banglang Huang
R: Jonas Karlman
S: Maintained
F: configs/rock-pi-e-rk3328_defconfig
-F: arch/arm/dts/rk3328-rock-pi-e.dts
-F: arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
+F: configs/rock-pi-e-v3-rk3328_defconfig
+F: arch/arm/dts/rk3328-rock-pi-e*
diff --git a/configs/rock-pi-e-v3-rk3328_defconfig
b/configs/rock-pi-e-v3-rk3328_defconfig
new file mode 100644
index 00..4c6cc634bd
--- /dev/null
+++ b/configs/rock-pi-e-v3-rk3328_defconfig
@@ -0,0 +1,97 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SPL_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SF_DEFAULT_SPEED=2000
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock-pi-e-v3"
+CONFIG_DM_RESET=y
+CONFIG_ROCKCHIP_RK3328=y
+CONFIG_DEBUG_UART_BASE=0xFF13
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SYS_LOAD_ADDR=0x800800
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/
Re: USB OTG mode for DWC3 (ie imx8mp) host controller with usb_ether USB Ethernet gadget?
On Mon, Jun 24, 2024 at 4:54 PM Adam Ford wrote: > I think some people tried to push a Type-C driver if memory serves, > but I think it was rejected. I don't recall the details and my memory > is terrible. :-) There is a recent series from Sebastian that adds USB Type-C support: https://lore.kernel.org/u-boot/20240604163546.60225-1-sebastian.reic...@collabora.com/
Re: USB OTG mode for DWC3 (ie imx8mp) host controller with usb_ether USB Ethernet gadget?
On Mon, Jun 24, 2024 at 12:54 PM Adam Ford wrote:
>
> On Mon, Jun 24, 2024 at 2:39 PM Tim Harvey wrote:
> >
> > Greetings,
> >
> > What is missing in U-Boot for the DWC3 host controller to support OTG
> > mode for usb_ether (USB Ethernet gadget)? I'm unable to get the usb
> > ethernet gadget to work for the imx8mp as it errors out with 'No UDC
> > available in the system'.
> >
> > The ums/acm/sdp gadget's all call udc_device_get_by_index to get the
> > UDC controller which for DWC3 is provided by
> > drivers/usb/dwc3/dwc3-generic.c and these gadgets work, however
> > usb_ether is different in that it calls usb_gadget_register_driver to
> > bind the gadget driver to the UDC and for DWC3 this calls
> > usb_gadget_probe_driver which iterates over udc_list which does not
> > contain DWC3 hosts that are in peripheral/otg mode.
> >
> > Before I spend a lot more time on this I wanted to see if anyone else
> > understands why boards with DWC3 host controllers like imx8mp don't
> > seem to register controllers in udc_list that are not in host mode.
> >
> > I'm also unclear how to get a DWC3 controller to switch roles
> > dynamically at runtime based on a gpio state for example. That support
> > appears to be missing and I'm not sure what the right way would be to
> > go about adding it. I notice that some imx8mp boards like the
> > imx8mp-evk have a u-boot.dtsi that just forces its OTG controller to
> > peripheral mode and I force the imx8mp-venice OTG controllers into
> > host mode.
>
> I think there is some interaction between the DWC controller and a
> type-c controller, but I think the mainline code lacks a proper type-c
> controller and/or framework. Not everyone might use a USB Type-C
> chip, but it seems like if the USB is set to dual-role, it could
> default to peripheral mode until someone starts the USB host stuff
> with 'usb start'
Agreed... if I override the controller to peripheral mode as is done
by Fabio for imx8mp-evk in commit b0eef7326920f ("imx8mp-evk: Add USB0
OTG support") I would expect peripheral mode to work and for imx8mp it
does indeed work for sdp/acm/ums just not for usb_ether.
I'm not clear if usb_ether is doing things the 'right way' or if the
others are doing it the right way and maybe they are both doing things
the right way and the issue I'm facing is that for whatever reason the
dwc3_generic_peripheral driver just doesn't get added to the udc_list.
>
> I am just not sure how to handle situations where a USB cable may be
> connected to a host computer and someone issues a start command and
> brings up VBUS which may cause a voltage contention.
If a USB start command is done the controller should check to make
sure it's in host mode before bringing up VBUS. This is done for the
ci_udc controller used in imx8mm for example. That controller uses the
USB_ID pin routed to the CI block when determining the role. There
does not currently appear to be any support for making role detection
generic such that an extcon driver or something like that could
provide the role functionality.
> I think some people tried to push a Type-C driver if memory serves,
> but I think it was rejected. I don't recall the details and my memory
> is terrible. :-)
you're not alone there! I rely heavily on notes but often forget where
my notes are :)
Tim
Re: USB OTG mode for DWC3 (ie imx8mp) host controller with usb_ether USB Ethernet gadget?
On Mon, Jun 24, 2024 at 2:39 PM Tim Harvey wrote: > > Greetings, > > What is missing in U-Boot for the DWC3 host controller to support OTG > mode for usb_ether (USB Ethernet gadget)? I'm unable to get the usb > ethernet gadget to work for the imx8mp as it errors out with 'No UDC > available in the system'. > > The ums/acm/sdp gadget's all call udc_device_get_by_index to get the > UDC controller which for DWC3 is provided by > drivers/usb/dwc3/dwc3-generic.c and these gadgets work, however > usb_ether is different in that it calls usb_gadget_register_driver to > bind the gadget driver to the UDC and for DWC3 this calls > usb_gadget_probe_driver which iterates over udc_list which does not > contain DWC3 hosts that are in peripheral/otg mode. > > Before I spend a lot more time on this I wanted to see if anyone else > understands why boards with DWC3 host controllers like imx8mp don't > seem to register controllers in udc_list that are not in host mode. > > I'm also unclear how to get a DWC3 controller to switch roles > dynamically at runtime based on a gpio state for example. That support > appears to be missing and I'm not sure what the right way would be to > go about adding it. I notice that some imx8mp boards like the > imx8mp-evk have a u-boot.dtsi that just forces its OTG controller to > peripheral mode and I force the imx8mp-venice OTG controllers into > host mode. I think there is some interaction between the DWC controller and a type-c controller, but I think the mainline code lacks a proper type-c controller and/or framework. Not everyone might use a USB Type-C chip, but it seems like if the USB is set to dual-role, it could default to peripheral mode until someone starts the USB host stuff with 'usb start' I am just not sure how to handle situations where a USB cable may be connected to a host computer and someone issues a start command and brings up VBUS which may cause a voltage contention. I think some people tried to push a Type-C driver if memory serves, but I think it was rejected. I don't recall the details and my memory is terrible. :-) adam > > Best Regards, > > Tim
USB OTG mode for DWC3 (ie imx8mp) host controller with usb_ether USB Ethernet gadget?
Greetings, What is missing in U-Boot for the DWC3 host controller to support OTG mode for usb_ether (USB Ethernet gadget)? I'm unable to get the usb ethernet gadget to work for the imx8mp as it errors out with 'No UDC available in the system'. The ums/acm/sdp gadget's all call udc_device_get_by_index to get the UDC controller which for DWC3 is provided by drivers/usb/dwc3/dwc3-generic.c and these gadgets work, however usb_ether is different in that it calls usb_gadget_register_driver to bind the gadget driver to the UDC and for DWC3 this calls usb_gadget_probe_driver which iterates over udc_list which does not contain DWC3 hosts that are in peripheral/otg mode. Before I spend a lot more time on this I wanted to see if anyone else understands why boards with DWC3 host controllers like imx8mp don't seem to register controllers in udc_list that are not in host mode. I'm also unclear how to get a DWC3 controller to switch roles dynamically at runtime based on a gpio state for example. That support appears to be missing and I'm not sure what the right way would be to go about adding it. I notice that some imx8mp boards like the imx8mp-evk have a u-boot.dtsi that just forces its OTG controller to peripheral mode and I force the imx8mp-venice OTG controllers into host mode. Best Regards, Tim
[ANN] U-Boot v2024.07-rc5 released
Hey all, Well, once again I need to check my calender reminders since, whoops, I'm a week late. That said, looking at the list of changes in this slightly elongated period, I think it's OK. At this point we're a week out from the release, so it's time for clear and obvious regression fixes. Ideally ones introduced this release cycle so there's less chances of unintended side-effects. In terms of a changelog, git log --merges v2024.07-rc4..v2024.07-rc5 contains what I've pulled but as always, better PR messages and tags will provide better results here. With that, the final release is planned for Monday, July 1st, 2024. Thanks all! -- Tom signature.asc Description: PGP signature
Re: Pull request for tpm-master-24062024
On Mon, Jun 24, 2024 at 03:29:56PM +0300, Ilias Apalodimas wrote: > Hi Tom, > > A few last minutes fixes for EFI, but this time via the TPM tree > > The following changes since commit fe2ce09a0753634543c32cafe85eb87a625f76ca: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-watchdog (2024-06-18 08:34:56 > -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tpm/ > tags/tpm-master-24062024 > > for you to fetch changes up to b73948c785d2bbccf0a76dec92cf50fe5b408c0e: > > efi_loader: fix the return values on efi_tcg (2024-06-24 08:38:06 +0300) > > The CI is here > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/21309 > and showed no problems. > > I also tested measured booot looking at the EventLog pre/post patch. No > changes > apart from PCR0 which is expected to change > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
Hi Fabio,
>Hi Paul,
>
>On Fri, Jun 21, 2024 at 10:06 AM Paul Geurts
> wrote:
>
>> -struct imx_sec_config_fuse_t {
>> +struct imx_fuse_t {
>
>Please make the struct renaming a separate patch.
Yes, I will do that.
>
>Peng Fan, Ye Li,
>
>Could you please help review this patch?
>
>Thanks
>
[PATCH] doc: fit: Make data-size a conditionally mandatory property
Before 9d0750064e (doc: Move external FIT docs into the main body), the FIT property data-size was not a mandatory property and still it is not expected to be set alongside the data property. Move the data-size property to the "Conditionally mandatory property" section, where it actually belongs. Signed-off-by: Bastian Germann --- doc/usage/fit/source_file_format.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/usage/fit/source_file_format.rst b/doc/usage/fit/source_file_format.rst index 7727ab77c5..15990e3ff5 100644 --- a/doc/usage/fit/source_file_format.rst +++ b/doc/usage/fit/source_file_format.rst @@ -254,9 +254,6 @@ compression zstd zstd compressed == -data-size -size of the data in bytes - Conditionally mandatory property @@ -276,6 +273,9 @@ data-position not relative to the loading of the FIT. This is mandatory if external data used with a fixed address. +data-size +Size of the data in bytes. This is mandatory if external data is used. + os OS name, mandatory for types "kernel". Valid OS names are: -- 2.45.2
Re: [PATCH 13/14] Update u-boot.cfg to include CFG also
On Sun, Jun 23, 2024 at 02:30:32PM -0600, Simon Glass wrote:
> Some configuration is now in variables with a CFG_ prefix. Add these to
> the .cfg file so that we can see everything in one place. Sort the
> options so they are easier to find and compare.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add new patch to update u-boot.cfg with CFG_... options
>
> scripts/Makefile.autoconf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
> index b42f9b525fe..65ff11ea508 100644
> --- a/scripts/Makefile.autoconf
> +++ b/scripts/Makefile.autoconf
> @@ -71,7 +71,7 @@ quiet_cmd_autoconf = GEN $@
> quiet_cmd_u_boot_cfg = CFG $@
>cmd_u_boot_cfg = \
> $(CPP) $(c_flags) $2 -DDO_DEPS_ONLY -dM include/config.h > $@.tmp && { \
> - grep 'define CONFIG_' $@.tmp | \
> + egrep 'define (CONFIG_|CFG_)' $@.tmp | sort | \
> sed '/define CONFIG_IS_ENABLED(/d;/define
> CONFIG_IF_ENABLED_INT(/d;/define CONFIG_VAL(/d;' > $@; \
> rm $@.tmp; \
> } || { \
I don't like this because whereas "CONFIG_" is enforced to be set only
by Kconfig and so always all reliably set and found via a single header,
CFG_ stuff is not.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 08/19] test: Introduce the concept of a role
On Sun, Jun 23, 2024 at 02:32:02PM -0600, Simon Glass wrote:
> In Labgrid there is the concept of a 'role', which is similar to the
> U-Boot board ID in U-Boot's pytest subsystem.
>
> The role indicates both the target and information about the U-Boot
> build to use. It can also provide any amount of other configuration.
> The information is obtained using the 'labgrid-client query' operation.
>
> Make use of this in tests, so that only the role is required in gitlab
> and other situations. The board type and other things can be queried
> as needed.
>
> Use a new 'u-boot-test-getrole' script to obtain the requested
> information.
>
> With this it is possible to run lab tests in gitlab with just a single
> 'ROLE' variable for each board.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> test/py/conftest.py | 31 +++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/test/py/conftest.py b/test/py/conftest.py
> index 6547c6922c6..5de8d7b0e23 100644
> --- a/test/py/conftest.py
> +++ b/test/py/conftest.py
> @@ -23,6 +23,7 @@ from pathlib import Path
> import pytest
> import re
> from _pytest.runner import runtestprotocol
> +import subprocess
> import sys
>
> # Globals: The HTML log file, and the connection to the U-Boot console.
> @@ -79,6 +80,7 @@ def pytest_addoption(parser):
> parser.addoption('--gdbserver', default=None,
> help='Run sandbox under gdbserver. The argument is the channel '+
> 'over which gdbserver should communicate, e.g. localhost:1234')
> +parser.addoption('--role', help='U-Boot board role (for Labgrid)')
> parser.addoption('--no-prompt-wait', default=False, action='store_true',
> help="Assume that U-Boot is ready and don't wait for a prompt")
>
> @@ -130,12 +132,33 @@ def get_details(config):
> str: Build directory
> str: Source directory
> """
> -board_type = config.getoption('board_type')
> -board_identity = config.getoption('board_identity')
> +role = config.getoption('role')
> build_dir = config.getoption('build_dir')
> +if role:
> +board_identity = role
> +cmd = ['u-boot-test-getrole', role, '--configure']
> +env = os.environ.copy()
> +if build_dir:
> +env['U_BOOT_BUILD_DIR'] = build_dir
> +proc = subprocess.run(cmd, capture_output=True, encoding='utf-8',
> + env=env)
> +if proc.returncode:
> +raise ValueError(proc.stderr)
> +print('conftest: lab:', proc.stdout)
> +vals = {}
> +for line in proc.stdout.splitlines():
> +item, value = line.split(' ', maxsplit=1)
> +k = item.split(':')[-1]
> +vals[k] = value
> +print('conftest: lab info:', vals)
> +board_type, default_build_dir, source_dir = (vals['board'],
> +vals['build_dir'], vals['source_dir'])
> +else:
> +board_type = config.getoption('board_type')
> +board_identity = config.getoption('board_identity')
>
> -source_dir = os.path.dirname(os.path.dirname(TEST_PY_DIR))
> -default_build_dir = source_dir + '/build-' + board_type
> +source_dir = os.path.dirname(os.path.dirname(TEST_PY_DIR))
> +default_build_dir = source_dir + '/build-' + board_type
> if not build_dir:
> build_dir = default_build_dir
I'm a little confused here. Why can't we construct "role" from
board_type+board_identity and then we have the board
conf.${board_type}_${board_identity} file set whatever needs setting to
be "labgrid" ?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 06/19] test: Avoid failing skipped tests
On Sun, Jun 23, 2024 at 02:32:00PM -0600, Simon Glass wrote:
> When a test returns -EAGAIN this should not be considered a failure.
> Fix what seems to be a problem case, where the pytests see a failure
> when a test has merely been skipped.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> test/test-main.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/test/test-main.c b/test/test-main.c
> index 3fa6f6e32ec..cda1a186390 100644
> --- a/test/test-main.c
> +++ b/test/test-main.c
> @@ -448,7 +448,7 @@ static int ut_run_test(struct unit_test_state *uts,
> struct unit_test *test,
> static int ut_run_test_live_flat(struct unit_test_state *uts,
>struct unit_test *test)
> {
> - int runs;
> + int runs, ret;
>
> if ((test->flags & UT_TESTF_OTHER_FDT) && !IS_ENABLED(CONFIG_SANDBOX))
> return skip_test(uts);
> @@ -458,8 +458,11 @@ static int ut_run_test_live_flat(struct unit_test_state
> *uts,
> if (CONFIG_IS_ENABLED(OF_LIVE)) {
> if (!(test->flags & UT_TESTF_FLAT_TREE)) {
> uts->of_live = true;
> - ut_assertok(ut_run_test(uts, test, test->name));
> - runs++;
> + ret = ut_run_test(uts, test, test->name);
> + if (ret != -EAGAIN) {
> + ut_assertok(ret);
> + runs++;
> + }
> }
> }
>
> @@ -483,8 +486,11 @@ static int ut_run_test_live_flat(struct unit_test_state
> *uts,
> (!runs || ut_test_run_on_flattree(test)) &&
> !(gd->flags & GD_FLG_FDT_CHANGED)) {
> uts->of_live = false;
> - ut_assertok(ut_run_test(uts, test, test->name));
> - runs++;
> + ret = ut_run_test(uts, test, test->name);
> + if (ret != -EAGAIN) {
> + ut_assertok(ret);
> + runs++;
> + }
> }
>
> return 0;
How did you trigger this case exactly?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 19/19] CI: Allow running tests on sjg lab
On Mon, Jun 24, 2024 at 04:56:02PM +0200, Michael Nazzareno Trimarchi wrote: > Hi Simon > > On Mon, Jun 24, 2024 at 2:52 PM Andrejs Cainikovs > wrote: > > > > On Sun, Jun 23, 2024 at 02:32:13PM -0600, Simon Glass wrote: > > > Add a way to run tests on a real hardware lab. This is in the very early > > > experimental stages. There are only 23 boards and 3 of those are broken! > > > (bob, ff3399, samus). A fourth fails due to problems with the TPM tests. > > > > > > To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.: > > > > > >git push -o ci.variable="SJG_LAB=1" dm HEAD:try > > > > > > This relies on the two previous series targeted at -next as well as the > > > bugfix series for -master > > > > > > Signed-off-by: Simon Glass > > > > Reviewed-by: Andrejs Cainikovs > > > > Do you have documentation on how to set it? We would like to do in our > company too I _think_ from some talking with Simon before the biggest sticking point might be changes needed on the labgrid side of things. However, that might also be most easily remedied if there's a few people showing up in the GitHub issue(s) showing interest in getting changes made/merged and to use the overall feature. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
On Sun, Jun 23, 2024 at 03:52:12PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 21 Jun 2024 at 16:12, Tom Rini wrote: > > > > On Fri, Jun 21, 2024 at 01:38:07PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 21 Jun 2024 at 13:19, Tom Rini wrote: > > > > > > > > On Fri, Jun 21, 2024 at 11:55:42AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Fri, 21 Jun 2024 at 10:05, Tom Rini wrote: > > > > [snip] > > > > > > Yes, I very much do not like guessing about 3 numbers instead of > > > > > > guessing about 1 number and using the standard mechanism we already > > > > > > have. Please use BOARD_SIZE_LIMIT as this is the standard mechanism > > > > > > to > > > > > > enforce size limits on U-Boot itself. > > > > > > > > > > If it were that easy I would have sent a patch :-) > > > > > > > > > > Here is the map for this board: > > > > > > > > > > ImagePosOffset Size Name > > > > > 0080 rom > > > > > ff80 ff80 1000 intel-descriptor > > > > > ff801000 ff801000 001ff000 intel-me > > > > > ffef ffef 000999f0 u-boot-with-ucode-ptr > > > > > fff899f0 fff899f0 5554 u-boot-dtb-with-ucode > > > > > fff8ef50 fff8ef50 u-boot-ucode > > > > > fff8ef50 fff8ef50 0571 fdtmap > > > > > fff9 fff9 0001 intel-vga > > > > > fffa fffa 0002fc94 intel-mrc > > > > > fffcfc94 fffcfc94 private-files > > > > > f800 f800 0070 x86-start16 > > > > > fff0 fff0 0005 x86-reset16 > > > > > fff8 fff8 0008 image-header > > > > > > > > > > What limit should I set on what? > > > > > > > > Is this a trick question? > > > > $ printf %d\\n $(( 0xfff9 - 0xffef)) > > > > 655360 > > > > > > > > Of course since we're less than that today, you can reduce it by > > > > whatever other magic numbers I'm not seeing but are part of your assumed > > > > sizes. > > > > > > That limit is on u-boot-nodtb.bin. Even with a size (for that file) of > > > 634816 it doesn't fit. I need to calculate a size based on the size of > > > the dtb and the microcode...which of course can change. > > > > Yes, and you're able to assume some size for them, which is what you > > put in the dts file? > > I just put in a limit for the blobs, whose sizes are known. > > > > > > > > - the U-Boot is the thing you are wanting to limit > > > > > - the dtb has microcode added > > > > > - the ucode is empty in this case > > > > > - the fdtmap is variable in size > > > > > > > > > > So this all seems a bit backwards. The actual limit is that > > > > > (u-boot-with-ucode-ptr + u-boot-dtb-with-ucode + u-boot-ucode + > > > > > fdtmap) fits in the space available. Note that some boards don't have > > > > > intel-vga or intel-mrc. > > > > > > > > > > With the other patch I sent I can have a sensible limit for all x86 > > > > > boards. > > > > > > Did you miss the comments above? > > > > No, I saw them. They're similar constraints to other systems. > > > > > > > > > > > And you can set the same sensible limit with the existing mechanism with > > > > the bonus of it not making x86 different from the rest? > > > > > > I understand that it is possible to set a limit for u-boot-nodtb.bin > > > but that is not accurate nor sufficient in the presence of blobs. The > > > solution belongs in Binman. > > > > Your series puts reasonable estimates on the size of the blobs and then > > will give a failure such as: > > binman: Node '/binman/rom/intel-vga': Offset 0xfff9 (4294508544) > > overlaps with previous entry '/binman/rom/fdtmap' ending at 0xfff902e1 > > (4294509281) > > Which is not as nice as (I just threw in a limit): > > u-boot-nodtb.bin exceeds file size limit: > > limit: 0x927c0 bytes > > actual: 0x9a810 bytes > > excess: 0x8050 bytes > > make[1]: *** [/home/trini/work/u-boot/u-boot/Makefile:1359: > > u-boot-nodtb.bin] Error 1 > > > > And tells us how much we need to get back size wise. Aside from when > > using the actual blobs (and in which case a real error will be shown > > when trying to use them), it's always about making an estimate on the > > part of the system that we control. > > Thanks for digging into this. > > I wasn't aware that the limit was just an estimate. Since it produces > a build error it seems to be enforced as a hard requirement. But I can > set a limit and we'll see how things go. > > I still like the binman block-size thing though. The error message > binman provides actually tells you what to do (reduce the space of the > things that are overflowing into intel-vga). So I'd like to add that > too. I think this is a reasonable compromise, thank you. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/8] Enable QoS for DSS on J7 family of TI SoCs
On Fri, 14 Jun 2024 18:14:34 +0530, Jayesh Choudhary wrote: > This series adds the QoS for DSS on J721E, J721S2 and J784S4 family of > SoCs. > > Before adding the support, cleanup is done for AM62A QoS support[0] > and common bit mask defines are moved to the common file so that they > are not defined every time we add QoS support for a new K3 platform. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH 05/14] sunxi: Mark scp as optional
Hello Simon,
On 2024-06-23 22:30, Simon Glass wrote:
This binary does not prevent the system from booting. Mark it optional
so that U-Boot can be built without it.
It should read "Lack of this binary..." instead, to properly describe
the background of this patch.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/dts/sunxi-u-boot.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi
b/arch/arm/dts/sunxi-u-boot.dtsi
index 0909a67883e..e1a9a7f5d4c 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -90,6 +90,7 @@
scp {
filename = "scp.bin";
missing-msg = "scp-sunxi";
+ optional;
};
};
#endif
Re: [PATCH v3 6/6] CI: Run code-coverage test for Binman
On Sun, Jun 23, 2024 at 11:56:22AM -0600, Simon Glass wrote: > Binman includes a good set of tests covering all of its functionality. > This includes a code-coverage test. > > However to date the code-coverage test has not been checked > automatically by CI, relying on people to run 'binman test -T' > themselves. > > Plug the gap to avoid bugs creeping in future. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/6] buildman: Always use the full path in CROSS_COMPILE
On Sun, Jun 23, 2024 at 11:56:20AM -0600, Simon Glass wrote: > The feature to set the toolchain path does not seem to be needed. It > causes problems with venv (see [1]). Let's remove it. > > Add some tests while we are here. > > It does not look like any docs changes are needed for this. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20240621131423.2363294-6-...@chromium.org/ > > Signed-off-by: Simon Glass > Suggested-by: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Sun, Jun 23, 2024 at 02:27:06AM +0200, Marek Vasut wrote: > This can also go into next if you prefer. > > The following changes since commit fe2ce09a0753634543c32cafe85eb87a625f76ca: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-watchdog (2024-06-18 08:34:56 > -0600) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to 0db3941a24bf0b6fc54438e7b9cc66b18f08115b: > > usb: dwc3: add newlines to dev_vdbg calls in ep0 (2024-06-19 06:15:37 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request doc-2024-07-rc5-2
On Sat, Jun 22, 2024 at 06:46:15PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit fe2ce09a0753634543c32cafe85eb87a625f76ca: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-watchdog (2024-06-18 > 08:34:56 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/doc-2024-07-rc5-2 > > for you to fetch changes up to 271ca9ef8a37b8668b9858638175ac2da5c152df: > > doc: board: ti: Add capsule documentation for TI K3 devices > (2024-06-22 17:04:19 +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/21289 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 1/4] Add fdt_kaslrseed function to add kaslr-seed to chosen node
On Thu, Jun 20, 2024 at 6:58 AM Caleb Connolly
wrote:
>
> Hi Tim,
>
> On 18/06/2024 23:06, Tim Harvey wrote:
> > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > randomize the virtual address at which the kernel image is loaded, it
> > expects entropy to be provided by the bootloader by populating
> > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
> >
> > Add a fdt_kaslrseed function to accommodate this allowing an existing
> > node to be overwritten if present. For now use the first rng device
> > but it would be good to enhance this in the future to allow some sort
> > of selection or policy in choosing the rng device used.
> >
> > Signed-off-by: Tim Harvey
> > Reviewed-by: Simon Glass
> > Cc: Michal Simek
> > Cc: Andy Yan
> > Cc: Akash Gajjar
> > Cc: Ilias Apalodimas
> > Cc: Simon Glass
> > Cc: Patrick Delaunay
> > Cc: Patrice Chotard
> > Cc: Devarsh Thakkar
> > Cc: Heinrich Schuchardt
> > Cc: Hugo Villeneuve
> > Cc: Marek Vasut
> > Cc: Tom Rini
> > Cc: Chris Morgan
> > ---
> > v6:
> > - collected tags
> > v5:
> > - move function to boot/fdt_support.c
> > - remove ability to select rng index and note in the commit log
> > something like this as a future enhancement.
> > - fixed typo in commit message s/it's/its/
> > - use cmd_process_error per Michal's suggestion
> > v4:
> > - add missing /n to notice in kaslrseed cmd
> > - combine ints in declaration
> > - remove unused vars from board/xilinx/common/board.c ft_board_setup
> > v3:
> > - skip if CONFIG_MEASURED_BOOT
> > - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> > - pass in rng index and bool to specify overwrite
> > - remove duplicate error strings printed outside of fdt_kaslrseed
> > - added note to commit log about how EFI STUB weeds out kalsr-seed
> > v2:
> > - fix typo in commit msg
> > - use stack for seed to avoid unecessary malloc/free
> > - move to a library function and deduplicate code by using it
> > elsewhere
> > ---
> > boot/fdt_support.c| 44 +++
> > include/fdt_support.h | 10 ++
> > 2 files changed, 54 insertions(+)
> >
> > diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> > index 2bd80a9dfb18..b1b2679dea0c 100644
> > --- a/boot/fdt_support.c
> > +++ b/boot/fdt_support.c
> > @@ -7,12 +7,15 @@
> >*/
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -274,6 +277,47 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
> > initrd_end)
> > return 0;
> > }
> >
> > +int fdt_kaslrseed(void *fdt, bool overwrite)
> > +{
> > + int len, err, nodeoffset;
> > + struct udevice *dev;
> > + const u64 *orig;
> > + u64 data = 0;
> > +
> > + err = fdt_check_header(fdt);
> > + if (err < 0)
> > + return err;
>
> All the paths that call fdt_kaslrseed() call fdt_check_header()
> beforehand, I think it's safe to drop this.
Hi Caleb,
The do_kaslr_seed path does not check for this and instead passes
working_fdt - perhaps your point is still valid if working_fdt is
guaranteed to always be a valid fdt?
> > +
> > + /* find or create "/chosen" node. */
> > + nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
> > + if (nodeoffset < 0)
> > + return nodeoffset;
>
> Arguably, this shouldn't be the responsibility of this function, maybe
> it would be better to error our here?
I'm not sure what your point is here... it is erroring out.
Best Regards,
Tim
> > +
> > + /* return without error if we are not overwriting and existing
> > non-zero node */
> > + orig = fdt_getprop(fdt, nodeoffset, "kaslr-seed", &len);
> > + if (orig && len == sizeof(*orig))
> > + data = fdt64_to_cpu(*orig);
> > + if (data && !overwrite) {
> > + debug("not overwriting existing kaslr-seed\n");
> > + return 0;
> > + }
> > + err = uclass_get_device(UCLASS_RNG, 0, &dev);
> > + if (err) {
> > + printf("No RNG device\n");
> > + return err;
> > + }
> > + err = dm_rng_read(dev, &data, sizeof(data));
> > + if (err) {
> > + dev_err(dev, "dm_rng_read failed: %d\n", err);
> > + return err;
> > + }
> > + err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", &data, sizeof(data));
> > + if (err < 0)
> > + printf("WARNING: could not set kaslr-seed %s.\n",
> > fdt_strerror(err));
> > +
> > + return err;
> > +}
> > +
> > /**
> >* board_fdt_chosen_bootargs - boards may override this function to use
> >* alternative kernel command line arguments
> > diff --git a/include/fdt_support.h b/include/fdt_support.h
> > index 4b71b8948d99..741e2360c224 100644
> > --- a/include/fdt_support.h
> > +++ b/include/fdt_support.h
> > @@ -
Re: [PATCH v3 19/19] CI: Allow running tests on sjg lab
Hi Simon
On Mon, Jun 24, 2024 at 2:52 PM Andrejs Cainikovs
wrote:
>
> On Sun, Jun 23, 2024 at 02:32:13PM -0600, Simon Glass wrote:
> > Add a way to run tests on a real hardware lab. This is in the very early
> > experimental stages. There are only 23 boards and 3 of those are broken!
> > (bob, ff3399, samus). A fourth fails due to problems with the TPM tests.
> >
> > To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.:
> >
> >git push -o ci.variable="SJG_LAB=1" dm HEAD:try
> >
> > This relies on the two previous series targeted at -next as well as the
> > bugfix series for -master
> >
> > Signed-off-by: Simon Glass
>
> Reviewed-by: Andrejs Cainikovs
>
Do you have documentation on how to set it? We would like to do in our
company too
Michael
> > ---
> >
> > Changes in v3:
> > - Split out most patches into two new series and update cover letter
> >
> > Changes in v2:
> > - Avoid running a docker image for skipped lab tests
> >
> > .gitlab-ci.yml | 153 +
> > 1 file changed, 153 insertions(+)
> >
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 165f765a833..75c18a0f2f7 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -17,6 +17,7 @@ stages:
> >- testsuites
> >- test.py
> >- world build
> > + - sjg-lab
> >
> > .buildman_and_testpy_template: &buildman_and_testpy_dfn
> >stage: test.py
> > @@ -482,3 +483,155 @@ coreboot test.py:
> > TEST_PY_TEST_SPEC: "not sleep"
> > TEST_PY_ID: "--id qemu"
> ><<: *buildman_and_testpy_dfn
> > +
> > +.lab_template: &lab_dfn
> > + stage: sjg-lab
> > + rules:
> > +- if: $SJG_LAB == "1"
> > + when: always
> > +- when: manual
> > + tags: [ 'lab' ]
> > + script:
> > +- if [[ -z "${SJG_LAB}" ]]; then
> > +exit 0;
> > + fi
> > +# Environment:
> > +# SRC - source tree
> > +# OUT - output directory for builds
> > +- export SRC="$(pwd)"
> > +- export OUT="${SRC}/build/${BOARD}"
> > +- export PATH=$PATH:~/bin
> > +- export PATH=$PATH:/vid/software/devel/ubtest/u-boot-test-hooks/bin
> > +
> > +# Load it on the device
> > +- ret=0
> > +- echo "role ${ROLE}"
> > +- export strategy="-s uboot -e off"
> > +# export verbose="-v"
> > +- ${SRC}/test/py/test.py --role ${ROLE} --build-dir "${OUT}"
> > +--capture=tee-sys -k "not bootstd"|| ret=$?
> > +- U_BOOT_BOARD_IDENTITY="${ROLE}" u-boot-test-release || true
> > +- if [[ $ret -ne 0 ]]; then
> > +exit $ret;
> > + fi
> > + artifacts:
> > +when: always
> > +paths:
> > + - "build/${BOARD}/test-log.html"
> > + - "build/${BOARD}/multiplexed_log.css"
> > +expire_in: 1 week
> > +
> > +rpi3:
> > + variables:
> > +ROLE: rpi3
> > + <<: *lab_dfn
> > +
> > +opi_pc:
> > + variables:
> > +ROLE: opi_pc
> > + <<: *lab_dfn
> > +
> > +pcduino3_nano:
> > + variables:
> > +ROLE: pcduino3_nano
> > + <<: *lab_dfn
> > +
> > +samus:
> > + variables:
> > +ROLE: samus
> > + <<: *lab_dfn
> > +
> > +link:
> > + variables:
> > +ROLE: link
> > + <<: *lab_dfn
> > +
> > +jerry:
> > + variables:
> > +ROLE: jerry
> > + <<: *lab_dfn
> > +
> > +minnowmax:
> > + variables:
> > +ROLE: minnowmax
> > + <<: *lab_dfn
> > +
> > +opi_pc2:
> > + variables:
> > +ROLE: opi_pc2
> > + <<: *lab_dfn
> > +
> > +bpi:
> > + variables:
> > +ROLE: bpi
> > + <<: *lab_dfn
> > +
> > +rpi2:
> > + variables:
> > +ROLE: rpi2
> > + <<: *lab_dfn
> > +
> > +bob:
> > + variables:
> > +ROLE: bob
> > + <<: *lab_dfn
> > +
> > +ff3399:
> > + variables:
> > +ROLE: ff3399
> > + <<: *lab_dfn
> > +
> > +coral:
> > + variables:
> > +ROLE: coral
> > + <<: *lab_dfn
> > +
> > +rpi3z:
> > + variables:
> > +ROLE: rpi3z
> > + <<: *lab_dfn
> > +
> > +bbb:
> > + variables:
> > +ROLE: bbb
> > + <<: *lab_dfn
> > +
> > +kevin:
> > + variables:
> > +ROLE: kevin
> > + <<: *lab_dfn
> > +
> > +pine64:
> > + variables:
> > +ROLE: pine64
> > + <<: *lab_dfn
> > +
> > +c4:
> > + variables:
> > +ROLE: c4
> > + <<: *lab_dfn
> > +
> > +rpi4:
> > + variables:
> > +ROLE: rpi4
> > + <<: *lab_dfn
> > +
> > +rpi0:
> > + variables:
> > +ROLE: rpi0
> > + <<: *lab_dfn
> > +
> > +snow:
> > + variables:
> > +ROLE: snow
> > + <<: *lab_dfn
> > +
> > +pcduino3:
> > + variables:
> > +ROLE: pcduino3
> > + <<: *lab_dfn
> > +
> > +nyan-big:
> > + variables:
> > +ROLE: nyan-big
> > + <<: *lab_dfn
> > --
> > 2.34.1
> >
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 0/5] usb: meson: switch to set_mode callback and other cleanup
On 6/24/24 11:11 AM, Neil Armstrong wrote: Hi Marek, Hi, On 20/06/2024 09:42, Neil Armstrong wrote: Switch to set_mode callback now it's available and in the same time make public functions static and drop useless mach-meson headers that are no more needed. Thanks for the review, is it ok to apply it via my tree ? Yes please
Re: [PATCH] usb: dwc3: respect role-switch-default-mode
On 6/24/24 1:41 PM, Caleb Connolly wrote:
Hi Marek,
On 24/06/2024 02:33, Marek Vasut wrote:
On 6/21/24 4:11 AM, Caleb Connolly wrote:
* Factor out the common pattern of checking the dr_mode property on
the usb node and it's parent
* Respect the usb-role-switch property, rather than requiring dr_mode be
set
* Override OTG mode with the value in role-switch-default-mode
The devicetree bindings don't dictate that dr_mode is a required
property, but the dwc3 driver would refuse to probe if it was unset
(this breaks the Qualcomm RB2 board which doesn't set it).
Here, we update the driver to respect the other properties that can be
used to describe the controller, and more gracefully handle some of the
edge cases.
Signed-off-by: Caleb Connolly
---
Cc: Ilias Apalodimas
Cc: Neil Armstrong
---
drivers/usb/dwc3/dwc3-generic.c | 56 +
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c
b/drivers/usb/dwc3/dwc3-generic.c
index cbb5d61dfb0b..1cf8b90e8bbf 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -49,8 +49,46 @@ struct dwc3_generic_host_priv {
struct dwc3_generic_priv gen_priv;
struct udevice *vbus_supply;
};
+/**
+ * dwc3_get_preferred_dr_mode() - Get the preferred DR mode for the
USB node
+ *
+ * Since we don't support dynamic role switching yet in dwc3, this
is a slightly
+ * opinionated wrapper around usb_get_dr_mode() which will respect the
+ * role-switch-default-mode property if it is present and the
dr_mode is OTG.
+ *
+ * @child: Node to get the DR mode for
+ */
+static enum usb_dr_mode dwc3_get_preferred_dr_mode(ofnode node)
+{
+ enum usb_dr_mode mode;
+ bool is_role_switch = ofnode_has_property(node, "usb-role-switch");
The usb-role-switch DT property is not DWC3 specific, even in U-Boot
it is used by e.g. STM32MP15xx which is DWC2. This should be added to
core code.
I couldn't see an obvious way to add this desired behaviour without
risking breaking some existing boards. Do you mean keep this as a new
function but just move it to core code?
Yes, make this available to other drivers by placing it into core code.
Or update the existing
get_dr_mode() function?
Better keep the get_dr_mode() as-is , I think the
get_preferred_dr_mode() is a superset, right ?
You could prepare a conversion series and switch other drivers over to
it, people can then test and selectively revert if something breaks.
Also, it would be really good to sync the DWC3 driver with more up to
date Linux state, but that's out of the scope of this patch obviously.
Yes, I'm definitely feeling this. Last time I tried updating dwc3 as you
suggested (reverting all patches since the Linux import, updating,
re-applying)... But there have just been too many changes on the Linux
side for this to work anymore, and too many arch specific dwc3 glue
drivers which call into the core that might break.
I am hoping these arch/ drivers should have been cleaned up by now, what
is there that is still open ?
I would love it if we could figure out some path forward here, even if
that's just someone spending more than half a day on the porting effort :D
I'd love to find a way to update too.
Re: [PATCH] ARM: imx: Enable SPL DTO application support for i.MX8MP DHCOM PDK2
On Sun, Jun 23, 2024 at 3:44 PM Marek Vasut wrote:
>
> Enable SPL DTO support to apply matching SoM specific DTOs to cater
> for the SoM differences in DH i.MX8MP DHCOM PDK2 configuration. This
> is already enabled in DH i.MX8MP DHCOM PDK3 configuration so align
> the two configurations.
>
> Fixes: ad1158c50e0e ("arm64: dts: imx8mp: Switch to DT overlays for i.MX8MP
> DHCOM SoM")
> Signed-off-by: Marek Vasut
Applied to u-boot-imx/next, thanks.
Re: [PATCH] imx8mp-venice-gw702x: Drop EQos clock workaround
Hi Tim, On Fri, Jun 21, 2024 at 12:42 PM Tim Harvey wrote: > Hi Fabio, > > It doesn't make much difference to me. This is a fix for a board model > that was renamed from gw7905 to gw7500 anyway which is a change in > dts/upstream I'm going to have to wait for anyway so you can leave it > for next if you want. I actually have about 8 patches in my repo to > dts/upstream from linux 6.9 and upcoming linux 6.10 as dts/upstream > was last merged from v6.8. > > The set of 5 or so patches I sent in the last few days are all fixes > of sorts and they are all isolated to board/gateworks/venice so don't > affect anyone else. Applied this one and your other patches to u-boot-imx/next, thanks.
Re: [PATCH] dt-bindings: imx: Drop redundant imports with dts/upstream
On Wed, Jun 19, 2024 at 12:10 PM Sumit Garg wrote: > > Drop redundant header imports with dts/upstream already providing > updated headers which have been checked to be backwards compatibility. > > The imx headers which aren't present in dts/upstream are as follows: > > - include/dt-bindings/clock/imxrt1020-clock.h > - include/dt-bindings/clock/imx8qm-clock.h > - include/dt-bindings/clock/imxrt1170-clock.h > - include/dt-bindings/clock/imx8qxp-clock.h > - include/dt-bindings/memory/imxrt-sdram.h > - include/dt-bindings/pinctrl/pads-imx8qxp.h > - include/dt-bindings/pinctrl/pads-imx8qm.h > - include/dt-bindings/soc/imx8_pd.h > - include/dt-bindings/soc/imx_rsrc.h > > hence these aren't dropped yet but there was an unused header: > > - include/dt-bindings/pinctrl/pins-imx8mq.h > > which has been dropped as well. There shouldn't be any funtional impact > with this change but it rather allows iMX platforms to use upstream > dt-bindings headers in a backwards compatible manner. > > Signed-off-by: Sumit Garg Applied to u-boot-imx/next, thanks.
Re: [PATCH] arm: fsl: imx6ulz_bsh_smm_m2: Migrate to OF_UPSTREAM
On Thu, Jun 13, 2024 at 7:24 AM Patrick Barsanti wrote: > > Migrate imx6ulz_bsh_smm_m2 board to OF_UPSTREAM. > > Signed-off-by: Patrick Barsanti Applied to u-boot-imx/next, thanks.
Re: [PATCH] arm: fsl: imx8mn_bsh_smm_s2: Migrate to OF_UPSTREAM
On Mon, Jun 10, 2024 at 6:23 PM Patrick Barsanti wrote: > > Migrate imx8mn_bsh_smm_s2 and imx8mn_bsh_smm_s2pro boards to OF_UPSTREAM. > > Signed-off-by: Patrick Barsanti > Tested-by: Michael Trimarchi Applied to u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240624
Hi Tom,
Please pull from u-boot-imx/next, thanks.
The following changes since commit 81e2b69880566a90e909a7e2c02dff0c39a8c1e5:
Merge patch series "boot: fix crash in bootflow menu with EFI BOOTMGR support
+ typos" (2024-06-20 11:41:43 -0600)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
tags/u-boot-imx-next-20240624
for you to fetch changes up to b7f677dc40429a8172c7ba5edcf3b426097e2881:
ARM: imx: Enable SPL DTO application support for i.MX8MP DHCOM PDK2
(2024-06-24 09:24:16 -0300)
u-boot-imx-next-20240624
--
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/21310
- Enable SPL DTO application support for i.MX8MP DHCOM PDK2.
- Migrate imx8mn_bsh_smm_s2 and imx6ulz_bsh_smm_m2 to OF_UPSTREAM.
- Drop redundant imports with dts/upstream.
- Miscellaneous improvements for Gateworks i.MX8M boards.
Marek Vasut (1):
ARM: imx: Enable SPL DTO application support for i.MX8MP DHCOM PDK2
Patrick Barsanti (2):
arm: fsl: imx8mn_bsh_smm_s2: Migrate to OF_UPSTREAM
arm: fsl: imx6ulz_bsh_smm_m2: Migrate to OF_UPSTREAM
Sumit Garg (1):
dt-bindings: imx: Drop redundant imports with dts/upstream
Tim Harvey (7):
board: gateworks: venice: enable GSC supervisor for new board models
board: gateworks: venice: delay before reading GSC EEPROM
board: gateworks: venice: add print for GPY111 PHY name
imx8m{m,p}_venice: add NVMe to boot devices
imx8mp-venice-gw74xx: default USB1 to host mode
imx8mp-venice-gw702x: Drop EQos clock workaround
board: gateworks: venice: Simplify Ethernet initialization
arch/arm/dts/Makefile | 3 -
arch/arm/dts/imx6ulz-bsh-smm-m2.dts | 146 --
arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi| 426 -
arch/arm/dts/imx8mn-bsh-smm-s2.dts| 48 --
arch/arm/dts/imx8mn-bsh-smm-s2pro.dts | 170 ---
arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi | 6 -
arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi | 5 +
arch/arm/mach-imx/imx8m/Kconfig | 2 +
arch/arm/mach-imx/mx6/Kconfig | 1 +
board/gateworks/venice/spl.c | 21 +-
board/gateworks/venice/venice.c | 22 +-
configs/imx6ulz_smm_m2_defconfig | 2 +-
configs/imx8mn_bsh_smm_s2_defconfig | 2 +-
configs/imx8mn_bsh_smm_s2pro_defconfig| 2 +-
configs/imx8mp_dhcom_pdk2_defconfig | 3 +-
include/configs/imx8mm_venice.h | 1 +
include/configs/imx8mp_venice.h | 1 +
include/dt-bindings/clock/imx5-clock.h| 219 -
include/dt-bindings/clock/imx6qdl-clock.h | 278 ---
include/dt-bindings/clock/imx6sl-clock.h | 178
include/dt-bindings/clock/imx6sll-clock.h | 210 -
include/dt-bindings/clock/imx6sx-clock.h | 281
include/dt-bindings/clock/imx6ul-clock.h | 262 ---
include/dt-bindings/clock/imx7d-clock.h | 456 ---
include/dt-bindings/clock/imx7ulp-clock.h | 119 -
include/dt-bindings/clock/imx8mm-clock.h | 286
include/dt-bindings/clock/imx8mn-clock.h | 262 ---
include/dt-bindings/clock/imx8mp-clock.h | 401
include/dt-bindings/clock/imx8mq-clock.h | 431 --
include/dt-bindings/clock/imx8ulp-clock.h | 258 ---
include/dt-bindings/clock/imx93-clock.h | 209 -
include/dt-bindings/clock/imxrt1050-clock.h | 72 ---
include/dt-bindings/interconnect/fsl,imx8mp.h | 59 ---
include/dt-bindings/interconnect/imx8mm.h | 50 --
include/dt-bindings/interconnect/imx8mn.h | 41 --
include/dt-bindings/interconnect/imx8mq.h | 48 --
include/dt-bindings/phy/phy-imx8-pcie.h | 14 -
include/dt-bindings/pinctrl/pins-imx8mq.h | 632 --
include/dt-bindings/power/fsl,imx93-power.h | 15 -
include/dt-bindings/power/imx7-power.h| 13 -
include/dt-bindings/power/imx8mm-power.h | 31 --
include/dt-bindings/power/imx8mn-power.h | 20 -
include/dt-bindings/power/imx8mp-power.h | 59 ---
include/dt-bindings/power/imx8mq-power.h | 24 -
include/dt-bindings/power/imx8ulp-power.h | 26 --
include/dt-bindings/reset/imx7-reset.h| 52 ---
include/dt-bindings/reset/imx8mp-reset.h | 50 --
include/dt-bindings/reset/imx8mq-reset.h | 67 ---
include/dt-bindings/reset/imx8ulp-pcc-reset.h | 59 ---
include/dt-bindings/sound/fsl-imx-audmux.h| 64 ---
50 files changed, 37 insertions(+), 6070 deletions(-)
delete mode 100644 arch/arm/dts/imx6ulz-bsh-smm-m2.dts
delete mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
delete mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2.dts
delete mode 100644 arch/arm/dts/imx8mn-bsh-smm
Re: [PATCH 2/3] rockchip: fix wrong PCI range address in rk3568 dtsi
Hi Etienne, On 6/24/24 2:40 PM, ETIENNE DUBLE wrote: One of the PCI ranges was wrong in this device tree. When testing with a FriendlyElec Nanopi R5C board, the 2nd ethernet interface (labelled "wan") was not working in u-boot because of that. With the correct value (found in FriendlyElec's downstream u-boot repository), this 2nd ethernet interface now works. Signed-off-by: Etienne Dublé --- dts/upstream/src/arm64/rockchip/rk3568.dtsi | 2 +- dts/upstream is only for patches coming from **merged** Linux kernel (i.e. releases or -rc releases or master branch from Linus Torvalds). We do not accept U-Boot-only patches in dts/upstream. Please submit the patch to the Linux kernel first and it will eventually make it to that directory either via a dts/update-dts-subtree.sh pull or dts/update-dts-subtree.sh pick. Depending on maintainer's opinion, fixing the range in arch/arm/dts/rk3568-u-boot.dtsi could be an option, but we really need the patch sent to upstream Linux kernel community first. c.f. https://www.kernel.org/doc/html/v6.5/process/submitting-patches.html Cheers, Quentin
Re: [PATCH 1/3] net: give a different name to rtl8169 interfaces
Hi Etienne,
On 6/24/24 2:40 PM, ETIENNE DUBLE wrote:
This commit implements the .bind member function,
and gives a different name to interfaces:
"RTL8169#0", "RTL8169#1", etc.
This was tested on a FriendlyElec Nanopi R5C board,
which has two RTL-8125B interfaces managed by this
driver. Since they were given the same name, it
was previously not possible to select the 2nd one
using ethact or ethprime environment variables.
Signed-off-by: Etienne Dublé
---
drivers/net/rtl8169.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 93e83661ce..b30d51731f 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -1091,6 +1091,16 @@ static int rtl8169_eth_probe(struct udevice *dev)
return 0;
}
+static int rtl8169_eth_bind(struct udevice *dev)
+{
+ static int card_number;
+ char name[16];
+
+ sprintf(name, "RTL8169#%u", card_number++);
+
+ return device_set_name(dev, name);
+}
+
I don't think we can guarantee bind order so this may not be stable over
time.
I'm wondering if there isn't a way to use the "ethernet" (ethernet0,
ethernet1) alias in DT instead?
Cheers,
Quentin
Re: [PATCH v2] mach-snapdragon: move default environment to a file
On 24/06/2024 14:31, Caleb Connolly wrote:
Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
environment to a file under board/qualcomm.
This is much cleaner and means we don't need to recompile on changing
the environment.
Signed-off-by: Caleb Connolly
---
Changes since v1:
- Don't set bootfile
- V1:
https://lore.kernel.org/u-boot/20240617085629.1744017-1-caleb.conno...@linaro.org
---
board/qualcomm/default.env | 11 +++
configs/qcom_defconfig | 2 ++
include/configs/qcom.h | 16
3 files changed, 13 insertions(+), 16 deletions(-)
create mode 100644 board/qualcomm/default.env
diff --git a/board/qualcomm/default.env b/board/qualcomm/default.env
new file mode 100644
index ..dbf6f4e72600
--- /dev/null
+++ b/board/qualcomm/default.env
@@ -0,0 +1,11 @@
+stdin=serial,button-kbd
+stdout=serial,vidconsole
+stderr=serial,vidconsole
+preboot=scsi scan; usb start
+fastboot=fastboot -l $fastboot_addr_r usb 0
+do_boot=bootefi bootmgr
+bootmenu_0=Boot first available device=run do_boot
+bootmenu_1=Enable fastboot mode=run fastboot
+bootmenu_2=Reset device=reset
+menucmd=bootmenu
+bootcmd=run do_boot
diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index 25fa8b0f7d2b..4ff280fc6e7d 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -46,8 +46,10 @@ CONFIG_CMD_LOG=y
CONFIG_OF_LIVE=y
CONFIG_OF_UPSTREAM_BUILD_VENDOR=y
CONFIG_BUTTON_QCOM_PMIC=y
CONFIG_BUTTON_REMAP_PHONE_KEYS=y
+CONFIG_USE_DEFAULT_ENV_FILE=y
+CONFIG_DEFAULT_ENV_FILE="board/qualcomm/default.env"
CONFIG_CLK=y
CONFIG_CLK_STUB=y
CONFIG_CLK_QCOM_APQ8016=y
CONFIG_CLK_QCOM_APQ8096=y
diff --git a/include/configs/qcom.h b/include/configs/qcom.h
index c13a847f62f1..b7d38866c51d 100644
--- a/include/configs/qcom.h
+++ b/include/configs/qcom.h
@@ -10,21 +10,5 @@
#define __CONFIGS_SNAPDRAGON_H
#define CFG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600, 300 }
-/* Load addressed are calculated during board_late_init(). See arm/mach-snapdragon/board.c */
-#define CFG_EXTRA_ENV_SETTINGS \
- "stdin=serial,button-kbd\0" \
- "stdout=serial,vidconsole\0" \
- "stderr=serial,vidconsole\0" \
- "bootfile=/extlinux/extlinux.conf\0" \
- "preboot=scsi scan; usb start\0" \
- "fastboot=fastboot -l $fastboot_addr_r usb 0\0" \
- "do_boot=bootefi bootmgr\0" \
- "bootmenu_0=Boot first available device=run do_boot\0" \
- "bootmenu_1=Enable USB mass storage=ums 0 scsi 0,1,2,3,4,5\0" \
- "bootmenu_2=Enable fastboot mode=run fastboot\0" \
- "bootmenu_3=Reset device=reset\0" \
- "menucmd=bootmenu\0" \
- "bootcmd=run do_boot\0" /* first entry is default */
-
#endif
Reviewed-by: Neil Armstrong
Re: [PATCH v2] spmi: msm: demote to debug()
On 24/06/2024 14:46, Caleb Connolly wrote:
Most devices have buttons exposed via the PMIC, the button polling
therefore triggers a log spam if debug logging is enabled.
Demote these to debug() so that they aren't printed unless LOG_DEBUG is
defined explicitly for this file.
Signed-off-by: Caleb Connolly
---
Changes since v1:
- use debug() instead of just commenting out
- V1:
https://lore.kernel.org/u-boot/20240607142229.50709-1-caleb.conno...@linaro.org
---
drivers/spmi/spmi-msm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index b0d6226041e5..a35cb0ba01e4 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -118,9 +118,9 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
return -EPERM;
channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
- dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);
+ debug("%s: [%d:%d] %s: channel %d\n", dev->name, usid, pid, __func__,
channel);
switch (priv->arb_ver) {
case V1:
ch_offset = SPMI_CH_OFFSET(channel);
@@ -185,9 +185,9 @@ static int msm_spmi_read(struct udevice *dev, int usid, int
pid, int off)
return -EIO;
channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
- dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);
+ debug("%s: [%d:%d] %s: channel %d\n", dev->name, usid, pid, __func__,
channel);
switch (priv->arb_ver) {
case V1:
ch_offset = SPMI_CH_OFFSET(channel);
Reviewed-by: Neil Armstrong
[PATCH 3/3] net: RTL-8125B -- write mac to MAC0_BKP
In the case of RTL-8125B, Linux reads the mac address
from register MAC0_BKP instead of MAC0, so let u-boot
write the mac address there.
Note: writing to MAC0 is still needed too, because this
register is used by the hardware for mac filtering (the
board will not receive packets if MAC0 is not set).
Tested on a FriendlyElec Nanopi R5C board.
Signed-off-by: Etienne Dublé
---
drivers/net/rtl8169.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index b30d51731f..7c4d658c6b 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -153,6 +153,7 @@ enum RTL8125_registers {
IntrMask_8125 = 0x38,
IntrStatus_8125 = 0x3C,
TxPoll_8125 = 0x90,
+ MAC0_BKP = 0x19e0,
};
enum RTL8169_register_content {
@@ -881,6 +882,7 @@ void rtl8169_eth_stop(struct udevice *dev)
static int rtl8169_write_hwaddr(struct udevice *dev)
{
struct eth_pdata *plat = dev_get_plat(dev);
+ struct pci_child_plat *pplat = dev_get_parent_plat(dev);
unsigned int i;
RTL_W8(Cfg9346, Cfg9346_Unlock);
@@ -888,6 +890,19 @@ static int rtl8169_write_hwaddr(struct udevice *dev)
for (i = 0; i < MAC_ADDR_LEN; i++)
RTL_W8(MAC0 + i, plat->enetaddr[i]);
+ /*
+* In the case of RTL8125, linux is reading the mac
+* address from register MAC0_BKP instead of MAC0,
+* so let's copy it there.
+* Note: we still need to write the mac to MAC0 too
+* (cf. the loop above) because the hardware uses MAC0
+* for mac filtering.
+*/
+ if (pplat->device == 0x8125) {
+ for (i = 0; i < MAC_ADDR_LEN; i++)
+ RTL_W8(MAC0_BKP + i, plat->enetaddr[i]);
+ }
+
RTL_W8(Cfg9346, Cfg9346_Lock);
return 0;
--
2.34.1
[PATCH 2/3] rockchip: fix wrong PCI range address in rk3568 dtsi
One of the PCI ranges was wrong in this device tree. When testing with a FriendlyElec Nanopi R5C board, the 2nd ethernet interface (labelled "wan") was not working in u-boot because of that. With the correct value (found in FriendlyElec's downstream u-boot repository), this 2nd ethernet interface now works. Signed-off-by: Etienne Dublé --- dts/upstream/src/arm64/rockchip/rk3568.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dts/upstream/src/arm64/rockchip/rk3568.dtsi b/dts/upstream/src/arm64/rockchip/rk3568.dtsi index f1be76a54c..06aac034ca 100644 --- a/dts/upstream/src/arm64/rockchip/rk3568.dtsi +++ b/dts/upstream/src/arm64/rockchip/rk3568.dtsi @@ -150,7 +150,7 @@ <0x0 0xf000 0x0 0x0010>; ranges = <0x0100 0x0 0xf010 0x0 0xf010 0x0 0x0010>, <0x0200 0x0 0xf020 0x0 0xf020 0x0 0x01e0>, -<0x0300 0x0 0x4000 0x3 0x8000 0x0 0x4000>; +<0x0300 0x0 0x8000 0x3 0x8000 0x0 0x4000>; reg-names = "dbi", "apb", "config"; resets = <&cru SRST_PCIE30X2_POWERUP>; reset-names = "pipe"; -- 2.34.1
[PATCH 1/3] net: give a different name to rtl8169 interfaces
This commit implements the .bind member function,
and gives a different name to interfaces:
"RTL8169#0", "RTL8169#1", etc.
This was tested on a FriendlyElec Nanopi R5C board,
which has two RTL-8125B interfaces managed by this
driver. Since they were given the same name, it
was previously not possible to select the 2nd one
using ethact or ethprime environment variables.
Signed-off-by: Etienne Dublé
---
drivers/net/rtl8169.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 93e83661ce..b30d51731f 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -1091,6 +1091,16 @@ static int rtl8169_eth_probe(struct udevice *dev)
return 0;
}
+static int rtl8169_eth_bind(struct udevice *dev)
+{
+ static int card_number;
+ char name[16];
+
+ sprintf(name, "RTL8169#%u", card_number++);
+
+ return device_set_name(dev, name);
+}
+
static const struct eth_ops rtl8169_eth_ops = {
.start = rtl8169_eth_start,
.send = rtl8169_eth_send,
@@ -1108,6 +1118,7 @@ U_BOOT_DRIVER(eth_rtl8169) = {
.name = "eth_rtl8169",
.id = UCLASS_ETH,
.of_match = rtl8169_eth_ids,
+ .bind = rtl8169_eth_bind,
.probe = rtl8169_eth_probe,
.ops= &rtl8169_eth_ops,
.priv_auto = sizeof(struct rtl8169_private),
--
2.34.1
[PATCH 0/3] Improve networking support on FriendlyElec Nanopi R5C
This board has two RTL-8125B interfaces (drivers/net/rtl8169.c). The secondary interface (labelled "wan") was not working because of a wrong PCI address in file rk3568.dtsi. Moreover, users could not instruct u-boot to use this secondary interface (i.e., using ethprime), because both interfaces had the same name. Lastly, the mac address generated by u-boot was not properly passed to the Linux kernel, in the case of RTL-8125B. This series probably improves support of other similar boards too (e.g., Nanopi R5S). Etienne Dublé (3): net: give a different name to rtl8169 interfaces rockchip: fix wrong PCI range address in rk3568 dtsi net: RTL-8125B -- write mac to MAC0_BKP drivers/net/rtl8169.c | 26 + dts/upstream/src/arm64/rockchip/rk3568.dtsi | 2 +- 2 files changed, 27 insertions(+), 1 deletion(-) -- 2.34.1
[PATCH] sandbox: Fix LTO to work with STACKPROTECTOR
Add the STACKPROTECTOR symbols to the script that generates the symbols that should not be removed by the use of LTO when linking a shared object. This prevents a fail to build due to link errors. https://source.denx.de/u-boot/u-boot/-/issues/35 Signed-off-by: Andrew Goodbody --- scripts/gen_ll_addressable_symbols.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/scripts/gen_ll_addressable_symbols.sh b/scripts/gen_ll_addressable_symbols.sh index d0864804aa..ebf89b04bf 100755 --- a/scripts/gen_ll_addressable_symbols.sh +++ b/scripts/gen_ll_addressable_symbols.sh @@ -13,3 +13,5 @@ set -e echo '#include ' $@ 2>/dev/null | grep -oe '_u_boot_list_2_[a-zA-Z0-9_]*_2_[a-zA-Z0-9_]*' | \ sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/' +$@ 2>/dev/null | grep -oe '__stack_chk_.*' | \ + sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/' -- 2.39.2
Re: [PATCH] imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
>> The decision on whether HAB is enabled is solely based on the SEC_CONFIG >> fuse. The HAB FIELD_RETURN feature is able to permanently disable HAB on >> a CPU, after which it is able to boot unsigned firmware. U-Boot however >> does not take into account the FIELD_RETURN mode, and refuses to boot >> unsigned software when the feature is enabled. >> >> Also take the FIELD_RETURN fuse into account when deciding whether HAB >> is enabled. When The FIELD_RETURN fuse is blown, HAB is not enabled. >> >> Tested on i.MX8M Mini, i.MX8M Plus, i.MX8M Nano and i.MX6ULL > >The purpose of the field return fuse is to unlock a system when it is >returned to factory, right ? That is the intention of the field return mode indeed. > >Can the system be re-locked afterward too ? No, the field return is enabled by a fuse, which cannot be reverted. The mode is intended to be able to perform investigations on broken devices, but these devices are not intended to go back into the field.
File renaming problem with systemd-boot after u-boot
Hello,
I am creating an update system using systemd (repart + sysupdate) and
systemd-boot on an embedded target (beaglebone black).
Everything seems to work except the bootcounting of systemd-boot. "Failed
to rename '\loader\entries\entry+3-0.conf' to 'entry+2-1.conf', ignoring:
Access denied". This happens when the function handle->SetInfo(handle,
MAKE_GUID_PTR(EFI_FILE_INFO), file_info_size, file_info) is called
(src/boot/efi/boot.c line 1385). Then the system is able to boot but I need
to get this bootcouting system working to be able to do fallback if the
update goes wrong.
According to the UEFI Specification we get Access denied after the call of
this function in these cases:
- An attempt is made to change the name of a file to a file that is already
present.
- An attempt is being made to change the EFI_FILE_DIRECTORY Attribute.
- An attempt is being made to change the size of a directory.
- InformationType is EFI_FILE_INFO_ID and the file was opened read-only and
an attempt is being made to modify a field other than Attribute.
However, none of these cases seem to happen because only the field FileName
is modified, the file is opened read/write before and the new name of the
file is not taken by another file.
I tried first to find the implementation of the SetInfo function to see in
more detail what is going wrong, but I didn't find it. Then, I tried to
identify the problem by printing the Attributes field of the EFI_FILE
\loader\entries\entry+3-0.conf. I found that this field is set to 0 and it
correspond to nothing :
- #define EFI_FILE_READ_ONLY 0x01U
- #define EFI_FILE_HIDDEN 0x02U
- #define EFI_FILE_SYSTEM 0x04U
- #define EFI_FILE_RESERVED 0x08U
- #define EFI_FILE_DIRECTORY 0x10U
- #define EFI_FILE_ARCHIVE0x20U
- #define EFI_FILE_VALID_ATTR 0x37U
I built the image with Yocto and here are the different partitions in the
image :
# u-boot partition
part --source uboot-part --ondisk mmcblk0 --fstype=vfat --label uboot
--active --align 1024 --fixed-size 32 --mbr
# esp partition
part --source esp-part --ondisk mmcblk0 --fstype=vfat --label esp --align
1024 --part-type C12A7328-F81F-11D2-BA4B-00A0C93EC93B
# recovery partition
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label recovery
--align 1024
# create gpt layout with mbr
bootloader --ptable=gpt-hybrid
systemd-boot was started by u-boot using the bootefi command :
fatload mmc 0:2 ${loadaddr} EFI/BOOT/bootarm.efi ; bootefi ${loadaddr}
So, my question is why do I get Access denied when I activate the
systemd-boot bootcounting ? Is it because the Attributes of the file
entry+3-0.conf is not set by u-boot ? If yes, how can I set it correctly ?
Re: [PATCH v3 19/19] CI: Allow running tests on sjg lab
On Sun, Jun 23, 2024 at 02:32:13PM -0600, Simon Glass wrote:
> Add a way to run tests on a real hardware lab. This is in the very early
> experimental stages. There are only 23 boards and 3 of those are broken!
> (bob, ff3399, samus). A fourth fails due to problems with the TPM tests.
>
> To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.:
>
>git push -o ci.variable="SJG_LAB=1" dm HEAD:try
>
> This relies on the two previous series targeted at -next as well as the
> bugfix series for -master
>
> Signed-off-by: Simon Glass
Reviewed-by: Andrejs Cainikovs
> ---
>
> Changes in v3:
> - Split out most patches into two new series and update cover letter
>
> Changes in v2:
> - Avoid running a docker image for skipped lab tests
>
> .gitlab-ci.yml | 153 +
> 1 file changed, 153 insertions(+)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 165f765a833..75c18a0f2f7 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -17,6 +17,7 @@ stages:
>- testsuites
>- test.py
>- world build
> + - sjg-lab
>
> .buildman_and_testpy_template: &buildman_and_testpy_dfn
>stage: test.py
> @@ -482,3 +483,155 @@ coreboot test.py:
> TEST_PY_TEST_SPEC: "not sleep"
> TEST_PY_ID: "--id qemu"
><<: *buildman_and_testpy_dfn
> +
> +.lab_template: &lab_dfn
> + stage: sjg-lab
> + rules:
> +- if: $SJG_LAB == "1"
> + when: always
> +- when: manual
> + tags: [ 'lab' ]
> + script:
> +- if [[ -z "${SJG_LAB}" ]]; then
> +exit 0;
> + fi
> +# Environment:
> +# SRC - source tree
> +# OUT - output directory for builds
> +- export SRC="$(pwd)"
> +- export OUT="${SRC}/build/${BOARD}"
> +- export PATH=$PATH:~/bin
> +- export PATH=$PATH:/vid/software/devel/ubtest/u-boot-test-hooks/bin
> +
> +# Load it on the device
> +- ret=0
> +- echo "role ${ROLE}"
> +- export strategy="-s uboot -e off"
> +# export verbose="-v"
> +- ${SRC}/test/py/test.py --role ${ROLE} --build-dir "${OUT}"
> +--capture=tee-sys -k "not bootstd"|| ret=$?
> +- U_BOOT_BOARD_IDENTITY="${ROLE}" u-boot-test-release || true
> +- if [[ $ret -ne 0 ]]; then
> +exit $ret;
> + fi
> + artifacts:
> +when: always
> +paths:
> + - "build/${BOARD}/test-log.html"
> + - "build/${BOARD}/multiplexed_log.css"
> +expire_in: 1 week
> +
> +rpi3:
> + variables:
> +ROLE: rpi3
> + <<: *lab_dfn
> +
> +opi_pc:
> + variables:
> +ROLE: opi_pc
> + <<: *lab_dfn
> +
> +pcduino3_nano:
> + variables:
> +ROLE: pcduino3_nano
> + <<: *lab_dfn
> +
> +samus:
> + variables:
> +ROLE: samus
> + <<: *lab_dfn
> +
> +link:
> + variables:
> +ROLE: link
> + <<: *lab_dfn
> +
> +jerry:
> + variables:
> +ROLE: jerry
> + <<: *lab_dfn
> +
> +minnowmax:
> + variables:
> +ROLE: minnowmax
> + <<: *lab_dfn
> +
> +opi_pc2:
> + variables:
> +ROLE: opi_pc2
> + <<: *lab_dfn
> +
> +bpi:
> + variables:
> +ROLE: bpi
> + <<: *lab_dfn
> +
> +rpi2:
> + variables:
> +ROLE: rpi2
> + <<: *lab_dfn
> +
> +bob:
> + variables:
> +ROLE: bob
> + <<: *lab_dfn
> +
> +ff3399:
> + variables:
> +ROLE: ff3399
> + <<: *lab_dfn
> +
> +coral:
> + variables:
> +ROLE: coral
> + <<: *lab_dfn
> +
> +rpi3z:
> + variables:
> +ROLE: rpi3z
> + <<: *lab_dfn
> +
> +bbb:
> + variables:
> +ROLE: bbb
> + <<: *lab_dfn
> +
> +kevin:
> + variables:
> +ROLE: kevin
> + <<: *lab_dfn
> +
> +pine64:
> + variables:
> +ROLE: pine64
> + <<: *lab_dfn
> +
> +c4:
> + variables:
> +ROLE: c4
> + <<: *lab_dfn
> +
> +rpi4:
> + variables:
> +ROLE: rpi4
> + <<: *lab_dfn
> +
> +rpi0:
> + variables:
> +ROLE: rpi0
> + <<: *lab_dfn
> +
> +snow:
> + variables:
> +ROLE: snow
> + <<: *lab_dfn
> +
> +pcduino3:
> + variables:
> +ROLE: pcduino3
> + <<: *lab_dfn
> +
> +nyan-big:
> + variables:
> +ROLE: nyan-big
> + <<: *lab_dfn
> --
> 2.34.1
>
Re: [PATCH v4 10/14] net-lwip: add wget command
Subject: [PATCH] net-lwip: Add message if not using http:// for wget
U-Boot's wget only supports http://, so give the user a clue if they don't
use it.
Signed-off-by: Jonathan Humphreys
---
net-lwip/wget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net-lwip/wget.c b/net-lwip/wget.c
index 63b19b99112..6b9c953ef51 100644
--- a/net-lwip/wget.c
+++ b/net-lwip/wget.c
@@ -35,8 +35,10 @@ static int parse_url(char *url, char *host, u16 *port, char
**path)
long lport;
p = strstr(url, "http://";);
- if (!p)
+ if (!p) {
+ log_err("only http:// is supported\n");
return -EINVAL;
+ }
p += strlen("http://";);
--
2.34.1
Re: [PATCH v4 10/14] net-lwip: add wget command
Subject: [PATCH] net-lwip: fixes off-by-one array access error with wget
When wget parses the url and extracts the host, it is off by one on the
index to terminate the character array.
Signed-off-by: Jonathan Humphreys
---
net-lwip/wget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net-lwip/wget.c b/net-lwip/wget.c
index 069299bd469..63b19b99112 100644
--- a/net-lwip/wget.c
+++ b/net-lwip/wget.c
@@ -51,7 +51,7 @@ static int parse_url(char *url, char *host, u16 *port, char
**path)
return -EINVAL;
memcpy(host, p, pp - p);
- host[pp - p + 1] = '\0';
+ host[pp - p] = '\0';
if (*pp == ':') {
/* Parse port number */
--
2.34.1
Re: [PATCH v4 10/14] net-lwip: add wget command
Jerome Forissier writes:
> Add support for the wget command with NET_LWIP.
>
> Based on code initially developed by Maxim U.
>
> Signed-off-by: Jerome Forissier
> Co-developed-by: Maxim Uvarov
> Cc: Maxim Uvarov
> Signed-off-by: Jerome Forissier
> ---
> cmd/Kconfig| 7 ++
> cmd/net-lwip.c | 8 ++
> include/net-lwip.h | 18 +++
> net-lwip/Makefile | 1 +
> net-lwip/wget.c| 269 +
> 5 files changed, 303 insertions(+)
> create mode 100644 net-lwip/wget.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 6ef0b52cd34..d9a86540be6 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2117,6 +2117,13 @@ config CMD_TFTPBOOT
> help
> tftpboot - load file via network using TFTP protocol
>
> +config CMD_WGET
> + bool "wget"
> + select PROT_TCP_LWIP
> + help
> + wget is a simple command to download kernel, or other files,
> + from a http server over TCP.
> +
> endif
>
> endif
> diff --git a/cmd/net-lwip.c b/cmd/net-lwip.c
> index c021da6a674..42f8bd6b259 100644
> --- a/cmd/net-lwip.c
> +++ b/cmd/net-lwip.c
> @@ -35,3 +35,11 @@ U_BOOT_CMD(
> "hostname [envvar]"
> );
> #endif
> +
> +#if defined(CONFIG_CMD_WGET)
> +U_BOOT_CMD(
> + wget, 3, 1, do_wget,
> + "boot image via network using HTTP protocol",
> + "[loadAddress] URL"
> +);
> +#endif
> diff --git a/include/net-lwip.h b/include/net-lwip.h
> index 4d41b0208a3..ddf25e61417 100644
> --- a/include/net-lwip.h
> +++ b/include/net-lwip.h
> @@ -11,8 +11,26 @@ struct netif *net_lwip_new_netif_noip(void);
> void net_lwip_remove_netif(struct netif *netif);
> struct netif *net_lwip_get_netif(void);
>
> +/**
> + * wget_with_dns() - runs dns host IP address resulution before wget
> + *
> + * @dst_addr:destination address to download the file
> + * @uri: uri string of target file of wget
> + * Return: downloaded file size, negative if failed
> + */
> +
> +int wget_with_dns(ulong dst_addr, char *uri);
> +/**
> + * wget_validate_uri() - varidate the uri
> + *
> + * @uri: uri string of target file of wget
> + * Return: true if uri is valid, false if uri is invalid
> + */
> +bool wget_validate_uri(char *uri);
> +
> int do_dhcp(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
> int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
> int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
> +int do_wget(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
>
> #endif /* __NET_LWIP_H__ */
> diff --git a/net-lwip/Makefile b/net-lwip/Makefile
> index aa247859483..bc011bb0e32 100644
> --- a/net-lwip/Makefile
> +++ b/net-lwip/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_DHCP) += dhcp.o
> obj-$(CONFIG_CMD_DNS) += dns.o
> obj-$(CONFIG_CMD_PING) += ping.o
> obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
> +obj-$(CONFIG_CMD_WGET) += wget.o
>
> # Disable this warning as it is triggered by:
> # sprintf(buf, index ? "foo%d" : "foo", index)
> diff --git a/net-lwip/wget.c b/net-lwip/wget.c
> new file mode 100644
> index 000..069299bd469
> --- /dev/null
> +++ b/net-lwip/wget.c
> @@ -0,0 +1,269 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (C) 2024 Linaro Ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SERVER_NAME_SIZE 200
> +#define HTTP_PORT_DEFAULT 80
> +#define PROGRESS_PRINT_STEP_BYTES (100 * 1024)
> +
> +enum done_state {
> +NOT_DONE = 0,
> +SUCCESS = 1,
> +FAILURE = 2
> +};
> +
> +struct wget_ctx {
> + ulong daddr;
> + ulong saved_daddr;
> + ulong size;
> + ulong prevsize;
> + ulong start_time;
> + enum done_state done;
> +};
> +
> +static int parse_url(char *url, char *host, u16 *port, char **path)
> +{
> + char *p, *pp;
> + long lport;
> +
> + p = strstr(url, "http://";);
> + if (!p)
> + return -EINVAL;
> +
> + p += strlen("http://";);
> +
> + /* Parse hostname */
> + pp = strchr(p, ':');
> + if (!pp)
> + pp = strchr(p, '/');
> + if (!pp)
> + return -EINVAL;
> +
> + if (p + SERVER_NAME_SIZE <= pp)
> + return -EINVAL;
> +
> + memcpy(host, p, pp - p);
> + host[pp - p + 1] = '\0';
> +
> + if (*pp == ':') {
> + /* Parse port number */
> + p = pp + 1;
> + lport = simple_strtol(p, &pp, 10);
> + if (pp && *pp != '/')
> + return -EINVAL;
> + if (lport > 65535)
> + return -EINVAL;
> + *port = (u16)lport;
> + } else {
> + *port = HTTP_PORT_DEFAULT;
> + }
> + if (*pp != '/')
> + return -EINVAL;
> + *path = pp;
> +
> + return 0;
> +}
> +
> +static err_t httpc_recv_cb(void *arg, struct altcp_pcb *pcb, struct pbuf
> *pbuf,
> +err_t err)
> +
[PATCH v2] spmi: msm: demote to debug()
Most devices have buttons exposed via the PMIC, the button polling
therefore triggers a log spam if debug logging is enabled.
Demote these to debug() so that they aren't printed unless LOG_DEBUG is
defined explicitly for this file.
Signed-off-by: Caleb Connolly
---
Changes since v1:
- use debug() instead of just commenting out
- V1:
https://lore.kernel.org/u-boot/20240607142229.50709-1-caleb.conno...@linaro.org
---
drivers/spmi/spmi-msm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index b0d6226041e5..a35cb0ba01e4 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -118,9 +118,9 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
return -EPERM;
channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
- dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);
+ debug("%s: [%d:%d] %s: channel %d\n", dev->name, usid, pid, __func__,
channel);
switch (priv->arb_ver) {
case V1:
ch_offset = SPMI_CH_OFFSET(channel);
@@ -185,9 +185,9 @@ static int msm_spmi_read(struct udevice *dev, int usid, int
pid, int off)
return -EIO;
channel = priv->channel_map[usid][pid] & SPMI_CHANNEL_MASK;
- dev_dbg(dev, "[%d:%d] %s: channel %d\n", usid, pid, __func__, channel);
+ debug("%s: [%d:%d] %s: channel %d\n", dev->name, usid, pid, __func__,
channel);
switch (priv->arb_ver) {
case V1:
ch_offset = SPMI_CH_OFFSET(channel);
--
2.45.0
[PATCH v2] mach-snapdragon: move default environment to a file
Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
environment to a file under board/qualcomm.
This is much cleaner and means we don't need to recompile on changing
the environment.
Signed-off-by: Caleb Connolly
---
Changes since v1:
- Don't set bootfile
- V1:
https://lore.kernel.org/u-boot/20240617085629.1744017-1-caleb.conno...@linaro.org
---
board/qualcomm/default.env | 11 +++
configs/qcom_defconfig | 2 ++
include/configs/qcom.h | 16
3 files changed, 13 insertions(+), 16 deletions(-)
create mode 100644 board/qualcomm/default.env
diff --git a/board/qualcomm/default.env b/board/qualcomm/default.env
new file mode 100644
index ..dbf6f4e72600
--- /dev/null
+++ b/board/qualcomm/default.env
@@ -0,0 +1,11 @@
+stdin=serial,button-kbd
+stdout=serial,vidconsole
+stderr=serial,vidconsole
+preboot=scsi scan; usb start
+fastboot=fastboot -l $fastboot_addr_r usb 0
+do_boot=bootefi bootmgr
+bootmenu_0=Boot first available device=run do_boot
+bootmenu_1=Enable fastboot mode=run fastboot
+bootmenu_2=Reset device=reset
+menucmd=bootmenu
+bootcmd=run do_boot
diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index 25fa8b0f7d2b..4ff280fc6e7d 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -46,8 +46,10 @@ CONFIG_CMD_LOG=y
CONFIG_OF_LIVE=y
CONFIG_OF_UPSTREAM_BUILD_VENDOR=y
CONFIG_BUTTON_QCOM_PMIC=y
CONFIG_BUTTON_REMAP_PHONE_KEYS=y
+CONFIG_USE_DEFAULT_ENV_FILE=y
+CONFIG_DEFAULT_ENV_FILE="board/qualcomm/default.env"
CONFIG_CLK=y
CONFIG_CLK_STUB=y
CONFIG_CLK_QCOM_APQ8016=y
CONFIG_CLK_QCOM_APQ8096=y
diff --git a/include/configs/qcom.h b/include/configs/qcom.h
index c13a847f62f1..b7d38866c51d 100644
--- a/include/configs/qcom.h
+++ b/include/configs/qcom.h
@@ -10,21 +10,5 @@
#define __CONFIGS_SNAPDRAGON_H
#define CFG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600, 300 }
-/* Load addressed are calculated during board_late_init(). See
arm/mach-snapdragon/board.c */
-#define CFG_EXTRA_ENV_SETTINGS \
- "stdin=serial,button-kbd\0" \
- "stdout=serial,vidconsole\0"\
- "stderr=serial,vidconsole\0" \
- "bootfile=/extlinux/extlinux.conf\0" \
- "preboot=scsi scan; usb start\0" \
- "fastboot=fastboot -l $fastboot_addr_r usb 0\0" \
- "do_boot=bootefi bootmgr\0" \
- "bootmenu_0=Boot first available device=run do_boot\0" \
- "bootmenu_1=Enable USB mass storage=ums 0 scsi 0,1,2,3,4,5\0" \
- "bootmenu_2=Enable fastboot mode=run fastboot\0" \
- "bootmenu_3=Reset device=reset\0" \
- "menucmd=bootmenu\0" \
- "bootcmd=run do_boot\0" /* first entry is default */
-
#endif
--
2.45.0
Pull request for tpm-master-24062024
Hi Tom, A few last minutes fixes for EFI, but this time via the TPM tree The following changes since commit fe2ce09a0753634543c32cafe85eb87a625f76ca: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-watchdog (2024-06-18 08:34:56 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-master-24062024 for you to fetch changes up to b73948c785d2bbccf0a76dec92cf50fe5b408c0e: efi_loader: fix the return values on efi_tcg (2024-06-24 08:38:06 +0300) The CI is here https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/21309 and showed no problems. I also tested measured booot looking at the EventLog pre/post patch. No changes apart from PCR0 which is expected to change When the EFI TCG measurement code moved from EFI to the TPM subsystem for general use some prototypes changed from returning efi_status_t to int, which is more appropriate for the non-EFI APIs. However, some of the EFI callsites never changed and we ended up assigning the int value to efi_status_t. This is unlikely to cause any problems, apart from returning invalid values on failures and violating the EFI spec. Ilias Apalodimas (2): tpm: fix the return code, if the eventlog buffer is full efi_loader: fix the return values on efi_tcg lib/efi_loader/efi_tcg2.c | 126 +- lib/tpm-v2.c | 2 +- 2 files changed, 70 insertions(+), 58 deletions(-)
Re: [PATCH] imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
Hi Paul,
On Fri, Jun 21, 2024 at 10:06 AM Paul Geurts
wrote:
> -struct imx_sec_config_fuse_t {
> +struct imx_fuse_t {
Please make the struct renaming a separate patch.
Peng Fan, Ye Li,
Could you please help review this patch?
Thanks
Re: [PATCH] usb: dwc3: respect role-switch-default-mode
Hi Marek,
On 24/06/2024 02:33, Marek Vasut wrote:
On 6/21/24 4:11 AM, Caleb Connolly wrote:
* Factor out the common pattern of checking the dr_mode property on
the usb node and it's parent
* Respect the usb-role-switch property, rather than requiring dr_mode be
set
* Override OTG mode with the value in role-switch-default-mode
The devicetree bindings don't dictate that dr_mode is a required
property, but the dwc3 driver would refuse to probe if it was unset
(this breaks the Qualcomm RB2 board which doesn't set it).
Here, we update the driver to respect the other properties that can be
used to describe the controller, and more gracefully handle some of the
edge cases.
Signed-off-by: Caleb Connolly
---
Cc: Ilias Apalodimas
Cc: Neil Armstrong
---
drivers/usb/dwc3/dwc3-generic.c | 56 +
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c
b/drivers/usb/dwc3/dwc3-generic.c
index cbb5d61dfb0b..1cf8b90e8bbf 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -49,8 +49,46 @@ struct dwc3_generic_host_priv {
struct dwc3_generic_priv gen_priv;
struct udevice *vbus_supply;
};
+/**
+ * dwc3_get_preferred_dr_mode() - Get the preferred DR mode for the
USB node
+ *
+ * Since we don't support dynamic role switching yet in dwc3, this is
a slightly
+ * opinionated wrapper around usb_get_dr_mode() which will respect the
+ * role-switch-default-mode property if it is present and the dr_mode
is OTG.
+ *
+ * @child: Node to get the DR mode for
+ */
+static enum usb_dr_mode dwc3_get_preferred_dr_mode(ofnode node)
+{
+ enum usb_dr_mode mode;
+ bool is_role_switch = ofnode_has_property(node, "usb-role-switch");
The usb-role-switch DT property is not DWC3 specific, even in U-Boot it
is used by e.g. STM32MP15xx which is DWC2. This should be added to core
code.
I couldn't see an obvious way to add this desired behaviour without
risking breaking some existing boards. Do you mean keep this as a new
function but just move it to core code? Or update the existing
get_dr_mode() function?
Also, it would be really good to sync the DWC3 driver with more up to
date Linux state, but that's out of the scope of this patch obviously.
Yes, I'm definitely feeling this. Last time I tried updating dwc3 as you
suggested (reverting all patches since the Linux import, updating,
re-applying)... But there have just been too many changes on the Linux
side for this to work anymore, and too many arch specific dwc3 glue
drivers which call into the core that might break.
I would love it if we could figure out some path forward here, even if
that's just someone spending more than half a day on the porting effort :D
--
// Caleb (they/them)
[PATCH] board: sifive: unmatched: remove extra space in fdtfile value
Fixes: 44a792c994 ("riscv: sifive: unmatched: migrate to text environment")
Signed-off-by: Andreas Schwab
---
board/sifive/unmatched/unmatched.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sifive/unmatched/unmatched.env
b/board/sifive/unmatched/unmatched.env
index 0f1e5a7174..34425dc9ef 100644
--- a/board/sifive/unmatched/unmatched.env
+++ b/board/sifive/unmatched/unmatched.env
@@ -16,4 +16,4 @@ partitions=
name=loader1,start=17K,size=1M,type=${type_guid_gpt_loader1};
name=loader2,size=4MB,type=${type_guid_gpt_loader2};
name=system,size=-,bootable,type=${type_guid_gpt_system};
-fdtfile= CONFIG_DEFAULT_FDT_FILE
+fdtfile=CONFIG_DEFAULT_FDT_FILE
--
2.45.2
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH 05/14] sunxi: Mark scp as optional
On Sun, 23 Jun 2024 14:30:24 -0600
Simon Glass wrote:
> This binary does not prevent the system from booting. Mark it optional
> so that U-Boot can be built without it.
>
> Signed-off-by: Simon Glass
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
> (no changes since v1)
>
> arch/arm/dts/sunxi-u-boot.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index 0909a67883e..e1a9a7f5d4c 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -90,6 +90,7 @@
> scp {
> filename = "scp.bin";
> missing-msg = "scp-sunxi";
> + optional;
> };
> };
> #endif
Re: [PATCH v1 1/3] mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
Hello Arseniy,
Am Sun, Jun 02, 2024 at 11:08:34PM +0300 schrieb Arseniy Krasnov:
> Based on Linux kernel:
> commit f922bd798bb9 ("mtd: rawnand: add an option to specify NAND chip as a
> boot device")
>
> Allow to define a NAND chip as a boot device. This can be helpful
> for the selection of the ECC algorithm and strength in case the boot
> ROM supports only a subset of controller provided options.
>
> Signed-off-by: Arseniy Krasnov
> ---
> drivers/mtd/nand/raw/nand_base.c | 3 +++
> include/linux/mtd/rawnand.h | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index c40a0f23d7..ed605b4af5 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4458,6 +4458,9 @@ static int nand_dt_init(struct mtd_info *mtd, struct
> nand_chip *chip, ofnode nod
> if (ret == 16)
> chip->options |= NAND_BUSWIDTH_16;
>
> + if (ofnode_read_bool(node, "nand-is-boot-medium"))
> + chip->options |= NAND_IS_BOOT_MEDIUM;
> +
> if (ofnode_read_bool(node, "nand-on-flash-bbt"))
> chip->bbt_options |= NAND_BBT_USE_FLASH;
>
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index fb002ae641..4eb880d8fb 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -218,6 +218,12 @@ enum nand_ecc_algo {
> /* Device needs 3rd row address cycle */
> #define NAND_ROW_ADDR_3 0x4000
>
> +/*
> + * Whether the NAND chip is a boot medium. Drivers might use this information
> + * to select ECC algorithms supported by the boot ROM or similar
> restrictions.
> + */
> +#define NAND_IS_BOOT_MEDIUM 0x0040
> +
> /* Options valid for Samsung large page devices */
> #define NAND_SAMSUNG_LP_OPTIONS NAND_CACHEPRG
The entries in that file are ordered numerically. Comparing with the
same file in Linux this should go before NAND_KEEP_TIMINGS, not
anywhere in between. Makes later diffs and ports from Linux easier.
Greets
Alex
>
> --
> 2.35.0
>
Re: [PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs
On Fri, Jun 21, 2024 at 07:11:28PM +0200, Caleb Connolly wrote:
> On Fri, 21 Jun 2024, 19:06 Vincent Stehlé, wrote:
>
> > On Fri, Jun 21, 2024 at 01:00:51PM +0200, Heinrich Schuchardt wrote:
> > (..)
> > > The current specification is in RFC 9562, 4.1, "Variant field"
> > >
> > > "The variant field consists of a variable number of the most significant
> > > bits of octet 8 of the UUID.
> > >
> > > ...
> > >
> > > Specifically for UUIDs in this document, bits 64 and 65 of the UUID
> > > (bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row 2
> > > of Table 1."
> > >
> > > This reference to byte 8 does not depend on endianness.
> >
> > Hi Heinrich,
> >
> > Agreed, variant is not concerned by the endianness.
> >
> > >
> > > U-Boot's include/uuid.h has:
> > >
> > > /* This is structure is in big-endian */
> > > struct uuid {
> > >
> > > The field time_hi_and_version needs to be stored in big-endian fashion.
> >
> > Thanks! I thought this structure was used to hold either a big-endian UUID
> > or a
> > little-endian GUID, but now you have convinced me.
> >
> > This confirms that the generation of the dynamic GUID is missing something:
> >
> > gen_uuid_v5(&namespace,
> > (struct uuid *)&fw_array[i].image_type_id,
> > compatible, strlen(compatible),
> > fw_array[i].fw_name, u16_strsize(fw_array[i].fw_name)
> > - sizeof(uint16_t),
> > NULL);
> >
> > It is not possible to cast the little-endian efi_guid_t .image_type_id as
> > the
> > big-endian struct uuid output of gen_uuid_v5() like this; we need to
> > convert the
> > three time fields from big to little endianness.
> >
>
> I'm inclined to disagree, the comment above struct uuid in include/uuid.h
> state clearly that the format in memory is always big endian, but that a
> GUID when printed has some fields converted to little endian.
Hi Caleb,
I read the comments above struct uuid differently: the GUID has some fields
little-endian when stored in memory (and can thus not be stored in a struct
uuid after Heinrich's comments).
This is consistent with how it is done in U-Boot in various locations; for
example, the EFI_GUID() macro stores a GUID with its time fields little-endian
in memory. Similarly, the callers of uuid_str_to_bin() or uuid_bin_to_str() with
format UUID_STR_FORMAT_GUID have indeed a little-endian GUID in memory (most
often an efi_guid_t). This is also consistent with the UEFI specification's
16-byte buffer format. [1]
When you have a big-endian UUID in memory, the version field is stored in byte
6, which is consistent with the RFC 9562. [2]
If you convert this big-endian UUID with uuid_bin_to_str() and
UUID_STR_FORMAT_GUID as in genguid, the "time high and version" field's bytes
will be printed with byte 7 first and then byte 6, as per guid_char_order[].
This is in contradiction with the RFC, which shows that the version field ("M")
should be printed first.
If you print the UUID with format 'STD, you will indeed have byte 6 containing
the version field printed first as it should (uuid_char_order[]).
This is confirmed by "uuid -d".
Best regards,
Vincent.
[1] https://uefi.org/specs/UEFI/2.10/Apx_A_GUID_and_Time_Formats.html
[2] https://www.rfc-editor.org/rfc/rfc9562
>
>
> > >
> > >
> > > tools/genguid uses UUID_STR_FORMAT_GUID which prints low-endian which is
> > > typical in the EFI context but not understood by 'uuid -d'. Maybe we
> > > should add a parameter for the output format.
> >
> > My understanding is that there is a single universal string format for both
> > UUIDs and GUIDs, which uuid -d understands, and which has no notion of
> > endianness. (Only the structures in memory have an endianness.)
> > This means we do not need an output format parameter.
> >
> > genguid is calling the new gen_uuid_v5() function, which outputs a
> > big-endian
> > struct uuid. Therefore, genguid should print it with 'STD format, not
> > 'GUID.
> >
> > Best regards,
> > Vincent.
> >
> > >
> > > Best regards
> > >
> > > Heinrich
> >
Re: [PATCH v2 0/5] usb: meson: switch to set_mode callback and other cleanup
Hi Marek, On 20/06/2024 09:42, Neil Armstrong wrote: Switch to set_mode callback now it's available and in the same time make public functions static and drop useless mach-meson headers that are no more needed. Thanks for the review, is it ok to apply it via my tree ? Thanks, Neil Signed-off-by: Neil Armstrong --- Changes in v2: - Update commit message in patch 1 to specify why we use _ in the set_mode callback - Link to v1: https://lore.kernel.org/r/20240618-u-boot-usb-gxl-phy-set-mode-v1-0-6b41efa46...@linaro.org --- Neil Armstrong (5): phy: meson-gxl-usb2: add set_mode callback usb: dwc3: meson-gxl: switch to generic_phy_set_mode phy: meson-gxl-usb2: remove phy_meson_gxl_usb2_set_mode usb: dwc3: meson-gxl: drop usb-gx.h and make dwc3_meson_gxl_force_mode static usb: dwc3: meson-g12a: drop usb.h and make dwc3_meson_g12a_force_mode static arch/arm/include/asm/arch-meson/usb-gx.h | 17 - arch/arm/include/asm/arch-meson/usb.h| 12 drivers/phy/meson-gxl-usb2.c | 30 ++ drivers/usb/dwc3/dwc3-meson-g12a.c | 2 +- drivers/usb/dwc3/dwc3-meson-gxl.c| 18 ++ 5 files changed, 29 insertions(+), 50 deletions(-) --- base-commit: f1de28e67aa9b66bfca0fad3dc18446a6ec0b504 change-id: 20240618-u-boot-usb-gxl-phy-set-mode-c3991c5f1da2 Best regards,
Re: [PATCH v1 1/3] mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
Hi, thanks, ok! What build problem ? With this [PATCH v1] mtd: rawnand:
macronix: OTP access for MX30LFxG18AC ?
Thanks
On 24.06.2024 11:37, Michael Nazzareno Trimarchi wrote:
> Hi
>
> Yes I have seen and I will review today and cross-check. Did you lunch
> the testing on the other patches series? I would like to merge
> at all but we were having some build breakage
>
> Michael
>
> On Mon, Jun 24, 2024 at 7:16 AM Arseniy Krasnov
> wrote:
>>
>> Hi, sorry, pls ping :)
>>
>> Thanks
>>
>> On 02.06.2024 23:08, Arseniy Krasnov wrote:
>>> Based on Linux kernel:
>>> commit f922bd798bb9 ("mtd: rawnand: add an option to specify NAND chip as a
>>> boot device")
>>>
>>> Allow to define a NAND chip as a boot device. This can be helpful
>>> for the selection of the ECC algorithm and strength in case the boot
>>> ROM supports only a subset of controller provided options.
>>>
>>> Signed-off-by: Arseniy Krasnov
>>> ---
>>> drivers/mtd/nand/raw/nand_base.c | 3 +++
>>> include/linux/mtd/rawnand.h | 6 ++
>>> 2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/mtd/nand/raw/nand_base.c
>>> b/drivers/mtd/nand/raw/nand_base.c
>>> index c40a0f23d7..ed605b4af5 100644
>>> --- a/drivers/mtd/nand/raw/nand_base.c
>>> +++ b/drivers/mtd/nand/raw/nand_base.c
>>> @@ -4458,6 +4458,9 @@ static int nand_dt_init(struct mtd_info *mtd, struct
>>> nand_chip *chip, ofnode nod
>>> if (ret == 16)
>>> chip->options |= NAND_BUSWIDTH_16;
>>>
>>> + if (ofnode_read_bool(node, "nand-is-boot-medium"))
>>> + chip->options |= NAND_IS_BOOT_MEDIUM;
>>> +
>>> if (ofnode_read_bool(node, "nand-on-flash-bbt"))
>>> chip->bbt_options |= NAND_BBT_USE_FLASH;
>>>
>>> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
>>> index fb002ae641..4eb880d8fb 100644
>>> --- a/include/linux/mtd/rawnand.h
>>> +++ b/include/linux/mtd/rawnand.h
>>> @@ -218,6 +218,12 @@ enum nand_ecc_algo {
>>> /* Device needs 3rd row address cycle */
>>> #define NAND_ROW_ADDR_3 0x4000
>>>
>>> +/*
>>> + * Whether the NAND chip is a boot medium. Drivers might use this
>>> information
>>> + * to select ECC algorithms supported by the boot ROM or similar
>>> restrictions.
>>> + */
>>> +#define NAND_IS_BOOT_MEDIUM 0x0040
>>> +
>>> /* Options valid for Samsung large page devices */
>>> #define NAND_SAMSUNG_LP_OPTIONS NAND_CACHEPRG
>>>
>
>
>
Re: [PATCH v4 14/16] rockchip: Avoid #ifdefs in RK3399 SPL
Hi Simon,
On 2024-06-23 19:53, Simon Glass wrote:
> The code here is confusing due to large blocks which are #ifdefed out.
> Add a function phase_sdram_init() which returns whether SDRAM init
> should happen in the current phase, using that as needed to control the
> code flow.
>
> This increases code size by about 500 bytes in SPL when the cache is on,
> since it must call the rather large rockchip_sdram_size() function.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v4:
> - Drop the non-dcache optimisation, since the cache should normally be on
>
> Changes in v3:
> - Split out the refactoring into a separate patch
>
> drivers/ram/rockchip/sdram_rk3399.c | 42 +++--
> 1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/ram/rockchip/sdram_rk3399.c
> b/drivers/ram/rockchip/sdram_rk3399.c
> index 3c4e20f4e80..949a082d00c 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ b/drivers/ram/rockchip/sdram_rk3399.c
[snip]
> @@ -191,6 +186,17 @@ struct io_setting {
> },
> };
>
> +/**
> + * phase_sdram_init() - Check if this is the phase where SDRAM init happens
> + *
> + * Returns: true to do SDRAM init in this phase, false to not
> + */
> +static bool phase_sdram_init(void)
> +{
> + return spl_phase() == PHASE_TPL ||
> + (!IS_ENABLED(CONFIG_TPL) && !spl_in_proper());
This also need to check for !IS_ENABLED(CONFIG_ROCKCHIP_EXTERNAL_TPL).
Regards,
Jonas
> +}
> +
[snip]
