Re: [PATCH v1] drivers: spi: sunxi: Fix spi speed settting
在 2022/6/28 8:34, Andre Przywara 写道:
On Thu, 9 Jun 2022 17:09:39 +0800
qianfangui...@163.com wrote:
Hi Qianfan,
From: qianfan Zhao
dm_spi_claim_bus run spi_set_speed_mode first and then ops->claim_bus,
but spi clock is enabled when sun4i_spi_claim_bus, that will make
sun4i_spi_set_speed doesn't work.
Thanks for bringing this up, and sorry for the delay (please CC: the
U-Boot sunxi maintainers!).
So this is very similar to the patch as I sent earlier:
https://lore.kernel.org/u-boot/20220503212040.27884-3-andre.przyw...@arm.com/
Can you please check whether this works for you as well, then reply to
that patch?
I put my version of the patch plus more fixes and F1C100s support to:
https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/commits/next/
Also I am curious under what circumstances and on what board you saw the
issue? In my case it was on the F1C100s, which has a higher base clock
(200 MHz instead of 24 MHz), so everything gets badly overclocked.
I tested based on those two commits:
spi: sunxi: refactor SPI speed/mode programming
spi: sunxi: improve SPI clock calculation
And there are a couple of questions:
1. sun4i_spi_of_to_plat try reading "spi-max-frequency" from the spi bus
node:
static int sun4i_spi_of_to_plat(struct udevice *bus)
{
struct sun4i_spi_plat *plat = dev_get_plat(bus);
int node = dev_of_offset(bus);
plat->base = dev_read_addr(bus);
plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
"spi-max-frequency",
SUN4I_SPI_DEFAULT_RATE);
if (plat->max_hz > SUN4I_SPI_MAX_RATE)
plat->max_hz = SUN4I_SPI_MAX_RATE;
return 0;
}
Seems this is not a correct way. "spi-max-frequency" should reading from
spi device,
not spi bus. On my dts, no "spi-max-frequency" prop on spi bus node,
this will make
plat->max_hz has default SUN4I_SPI_DEFAULT_RATE(1M) value.
{
pinctrl-names = "default";
pinctrl-0 = <_cs0_pb_pin _pb_pins>;
status = "okay";
lcd@0 {
compatible = "sitronix,st75161";
spi-max-frequency = <1200>;
reg = <0>;
spi-cpol;
spi-cpha;
So on my patch, I had changed the default plat->max_hz to
SUN4I_SPI_MAX_RATE.
2. When I changed the default plat->max_hz to SUN4I_SPI_MAX_RATE:
2.1: sun4i_spi_set_speed_mode doesn't consider when div = 1(freq =
SUNXI_INPUT_CLOCK),
the spi running in 12M even if the spi-max-frequency is setted to 24M.
2.2: on my R40 based board, spi can't work when the spi clock <= 6M.
I had check the CCR register, the value is correct, from logic analyzer
only the first byte is sent. Next is the serial console logs:
spi clock = 6M:
CCR: 1001
ERROR: sun4i_spi: Timeout transferring data
ERROR: sun4i_spi: Timeout transferring data
ERROR: sun4i_spi: Timeout transferring data
...
spi clock = 4M:
CCR: 1002
ERROR: sun4i_spi: Timeout transferring data
ERROR: sun4i_spi: Timeout transferring data
ERROR: sun4i_spi: Timeout transferring data
ERROR: sun4i_spi: Timeout transferring data
ERROR: sun4i_spi: Timeout transferring data
...
Thanks!
Andre
Fix it.
Signed-off-by: qianfan Zhao
---
drivers/spi/spi-sunxi.c | 78 -
1 file changed, 30 insertions(+), 48 deletions(-)
diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
index b6cd7ddafa..1043cde976 100644
--- a/drivers/spi/spi-sunxi.c
+++ b/drivers/spi/spi-sunxi.c
@@ -224,6 +224,7 @@ err_ahb:
static int sun4i_spi_claim_bus(struct udevice *dev)
{
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
+ u32 div, reg;
int ret;
ret = sun4i_spi_set_clock(dev->parent, true);
@@ -233,12 +234,38 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
setbits_le32(SPI_REG(priv, SPI_GCR), SUN4I_CTL_ENABLE |
SUN4I_CTL_MASTER | SPI_BIT(priv, SPI_GCR_TP));
+ /* Setup clock divider */
+ div = SUN4I_SPI_MAX_RATE / (2 * priv->freq);
+ reg = readl(SPI_REG(priv, SPI_CCR));
+
+ if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
+ if (div > 0)
+ div--;
+
+ reg &= ~(SUN4I_CLK_CTL_CDR2_MASK | SUN4I_CLK_CTL_DRS);
+ reg |= SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
+ } else {
+ div = __ilog2(SUN4I_SPI_MAX_RATE) - __ilog2(priv->freq);
+ reg &= ~((SUN4I_CLK_CTL_CDR1_MASK << 8) | SUN4I_CLK_CTL_DRS);
+ reg |= SUN4I_CLK_CTL_CDR1(div);
+ }
+
+ writel(reg, SPI_REG(priv, SPI_CCR));
+
if (priv->variant->has_soft_reset)
setbits_le32(SPI_REG(priv, SPI_GCR),
SPI_BIT(priv, SPI_GCR_SRST));
- setbits_le32(SPI_REG(priv, SPI_TCR), SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
-SPI_BIT(priv, SPI_TCR_CS_ACTIVE_LOW));
+ /* Setup the transfer control register */
+ reg = SPI_BIT(priv, SPI_TCR_CS_MANUAL) |
+
[PATCH] usb: host: ehci-generic: Fix error check
Commit 81755b8c20fe ("usb: host: ehci-generic: Make resets and clocks
optional") improved the error check to cover the reset property being
optional. However this was using the wrong error variable for the
check, so would now never fail.
Use the correct error variable for checking the result of
reset_get_bulk(), to actually report genuine errors.
Fixes: 81755b8c20fe ("usb: host: ehci-generic: Make resets and clocks optional")
Signed-off-by: Andre Przywara
---
Hi,
apologies for messing up this simple patch of mine last month. I got
confused by the mixed usage of "ret" and "err" in this function. This
might endorse some cleanup, but I don't dare to touch this file again,
especially not that late in the cycle.
Cheers,
Andre
drivers/usb/host/ehci-generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index 15267e9a05a..75c73bfe4e8 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -81,7 +81,7 @@ static int ehci_usb_probe(struct udevice *dev)
}
err = reset_get_bulk(dev, >resets);
- if (ret && ret != -ENOENT) {
+ if (err && err != -ENOENT) {
dev_err(dev, "Failed to get resets (err=%d)\n", err);
goto clk_err;
}
--
2.35.3
[PATCH v2 6/6] patman: Take project defaults into account for --help
I'd like it so that when you do "patman send --help" and you're using
Linux that it show it the proper defaults for Linux.
Signed-off-by: Douglas Anderson
Tested-by: Brian Norris
---
Changes in v2:
- Make comment about parsing three times less nonsensical.
tools/patman/main.py | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/patman/main.py b/tools/patman/main.py
index feb26f22e46c..792124bb7555 100755
--- a/tools/patman/main.py
+++ b/tools/patman/main.py
@@ -108,14 +108,19 @@ status.add_argument('-d', '--dest-branch', type=str,
status.add_argument('-f', '--force', action=BooleanOptionalAction,
help='Force overwriting an existing branch')
-# Parse options twice: first to get the project and second to handle
-# defaults properly (which depends on project)
-# Use parse_known_args() in case 'cmd' is omitted
+# Parse options several times:
+# - First to get the project.
+# - Second to handle defaults properly (which depends on project). This
+# makes help display the right defaults.
+# - Finally after we have added an implicit command if necessary.
+#
+# Use parse_known_args() for the first two in case 'cmd' is omitted
+argv = [arg for arg in sys.argv[1:] if arg not in ('-h', '--help')]
+args, _ = parser.parse_known_args(argv)
argv = sys.argv[1:]
-args, rest = parser.parse_known_args(argv)
if hasattr(args, 'project'):
settings.Setup(gitutil, parser, args.project, '')
-args, rest = parser.parse_known_args(argv)
+args, rest = parser.parse_known_args(argv)
# If we have a command, it is safe to parse all arguments
if args.cmd:
--
2.37.0.rc0.161.g10f37bed90-goog
[PATCH v2 5/6] patman: By default don't pass "--no-tree" to checkpatch for linux
When you pass "--no-tree" to checkpatch it disables some extra checks
that are important for Linux. Specifically I want checks like:
warning: DT compatible string "boogie,woogie" appears un-documented
check ./Documentation/devicetree/bindings/
Let's make the default for Linux to _not_ pass --no-tree. We'll have a
config option and command line flag to override.
Signed-off-by: Douglas Anderson
Tested-by: Brian Norris
Reviewed-by: Brian Norris
---
(no changes since v1)
tools/patman/checkpatch.py | 11 +++
tools/patman/control.py| 7 ---
tools/patman/main.py | 3 +++
tools/patman/settings.py | 3 ++-
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
index 70ba561c2686..d1b902dd9627 100644
--- a/tools/patman/checkpatch.py
+++ b/tools/patman/checkpatch.py
@@ -186,7 +186,7 @@ def check_patch_parse(checkpatch_output, verbose=False):
return result
-def check_patch(fname, verbose=False, show_types=False):
+def check_patch(fname, verbose=False, show_types=False, use_tree=False):
"""Run checkpatch.pl on a file and parse the results.
Args:
@@ -194,6 +194,7 @@ def check_patch(fname, verbose=False, show_types=False):
verbose: True to print out every line of the checkpatch output as it is
parsed
show_types: Tell checkpatch to show the type (number) of each message
+use_tree (bool): If False we'll pass '--no-tree' to checkpatch.
Returns:
namedtuple containing:
@@ -210,7 +211,9 @@ def check_patch(fname, verbose=False, show_types=False):
stdout: Full output of checkpatch
"""
chk = find_check_patch()
-args = [chk, '--no-tree']
+args = [chk]
+if not use_tree:
+args.append('--no-tree')
if show_types:
args.append('--show-types')
output = command.output(*args, fname, raise_on_error=False)
@@ -236,13 +239,13 @@ def get_warning_msg(col, msg_type, fname, line, msg):
line_str = '' if line is None else '%d' % line
return '%s:%s: %s: %s\n' % (fname, line_str, msg_type, msg)
-def check_patches(verbose, args):
+def check_patches(verbose, args, use_tree):
'''Run the checkpatch.pl script on each patch'''
error_count, warning_count, check_count = 0, 0, 0
col = terminal.Color()
for fname in args:
-result = check_patch(fname, verbose)
+result = check_patch(fname, verbose, use_tree=use_tree)
if not result.ok:
error_count += result.errors
warning_count += result.warnings
diff --git a/tools/patman/control.py b/tools/patman/control.py
index b40382388e07..bf426cf7bcf4 100644
--- a/tools/patman/control.py
+++ b/tools/patman/control.py
@@ -64,7 +64,7 @@ def prepare_patches(col, branch, count, start, end,
ignore_binary, signoff):
patchstream.insert_cover_letter(cover_fname, series, to_do)
return series, cover_fname, patch_files
-def check_patches(series, patch_files, run_checkpatch, verbose):
+def check_patches(series, patch_files, run_checkpatch, verbose, use_tree):
"""Run some checks on a set of patches
This santiy-checks the patman tags like Series-version and runs the patches
@@ -77,6 +77,7 @@ def check_patches(series, patch_files, run_checkpatch,
verbose):
run_checkpatch (bool): True to run checkpatch.pl
verbose (bool): True to print out every line of the checkpatch output
as
it is parsed
+use_tree (bool): If False we'll pass '--no-tree' to checkpatch.
Returns:
bool: True if the patches had no errors, False if they did
@@ -86,7 +87,7 @@ def check_patches(series, patch_files, run_checkpatch,
verbose):
# Check the patches, and run them through 'git am' just to be sure
if run_checkpatch:
-ok = checkpatch.check_patches(verbose, patch_files)
+ok = checkpatch.check_patches(verbose, patch_files, use_tree)
else:
ok = True
return ok
@@ -165,7 +166,7 @@ def send(args):
col, args.branch, args.count, args.start, args.end,
args.ignore_binary, args.add_signoff)
ok = check_patches(series, patch_files, args.check_patch,
- args.verbose)
+ args.verbose, args.check_patch_use_tree)
ok = ok and gitutil.check_suppress_cc_config()
diff --git a/tools/patman/main.py b/tools/patman/main.py
index 66424f15c204..feb26f22e46c 100755
--- a/tools/patman/main.py
+++ b/tools/patman/main.py
@@ -83,6 +83,9 @@ send.add_argument('--binary', action=BooleanOptionalAction,
send.add_argument('--check', action=BooleanOptionalAction, dest='check_patch',
default=True,
help="Check for patch compliance")
+send.add_argument('--tree', action=BooleanOptionalAction,
+ dest='check_patch_use_tree', default=False,
+ help="If False, pass '--no-tree' to checkpatch")
send.add_argument('--tags',
[PATCH v2 4/6] patman: Make most bool arguments BooleanOptionalAction
For boolean arguments it's convenient to be able to specify both the
argument and its opposite on the command line. This is especially
convenient because you can change the default via the settings file
and being able express the opposite can be the only way to override
things.
Luckily python handles this well--we just need to specify things with
BooleanOptionalAction. We'll do that for all options except
"full-help" (where it feels silly). This uglifies the help text a
little bit but does give maximum flexibility.
Signed-off-by: Douglas Anderson
Tested-by: Brian Norris
Reviewed-by: Brian Norris
---
Changes in v2:
- Fix doc string for --ignore-bad-tags
tools/patman/main.py | 55 ++--
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/tools/patman/main.py b/tools/patman/main.py
index 336f4e439aa9..66424f15c204 100755
--- a/tools/patman/main.py
+++ b/tools/patman/main.py
@@ -6,7 +6,7 @@
"""See README for more information"""
-from argparse import ArgumentParser
+from argparse import ArgumentParser, BooleanOptionalAction
import os
import re
import shutil
@@ -40,7 +40,7 @@ parser.add_argument('-c', '--count', dest='count', type=int,
default=-1, help='Automatically create patches from top n commits')
parser.add_argument('-e', '--end', type=int, default=0,
help='Commits to skip at end of patch list')
-parser.add_argument('-D', '--debug', action='store_true',
+parser.add_argument('-D', '--debug', action=BooleanOptionalAction,
help='Enabling debugging (provides a full traceback on error)')
parser.add_argument('-p', '--project', default=project.detect_project(),
help="Project name; affects default option values and "
@@ -50,42 +50,43 @@ parser.add_argument('-P', '--patchwork-url',
help='URL of patchwork server [default: %(default)s]')
parser.add_argument('-s', '--start', dest='start', type=int,
default=0, help='Commit to start creating patches from (0 = HEAD)')
-parser.add_argument('-v', '--verbose', action='store_true', dest='verbose',
-default=False, help='Verbose output of errors and
warnings')
+parser.add_argument('-v', '--verbose', action=BooleanOptionalAction,
+dest='verbose', default=False,
+help='Verbose output of errors and warnings')
parser.add_argument('-H', '--full-help', action='store_true', dest='full_help',
default=False, help='Display the README file')
subparsers = parser.add_subparsers(dest='cmd')
send = subparsers.add_parser('send')
-send.add_argument('-i', '--ignore-errors', action='store_true',
- dest='ignore_errors', default=False,
- help='Send patches email even if patch errors are found')
+send.add_argument('-i', '--ignore-errors', action=BooleanOptionalAction,
+ dest='ignore_errors', default=False,
+ help='Send patches email even if patch errors are found')
send.add_argument('-l', '--limit-cc', dest='limit', type=int, default=None,
help='Limit the cc list to LIMIT entries [default: %(default)s]')
-send.add_argument('-m', '--no-maintainers', action='store_false',
- dest='add_maintainers', default=True,
- help="Don't cc the file maintainers automatically")
-send.add_argument('-n', '--dry-run', action='store_true', dest='dry_run',
- default=False, help="Do a dry run (create but don't email patches)")
+send.add_argument('-m', '--maintainers', action=BooleanOptionalAction,
+ dest='add_maintainers', default=True,
+ help="cc the file maintainers automatically")
+send.add_argument('-n', '--dry-run', action=BooleanOptionalAction,
+ dest='dry_run', default=False,
+ help="Do a dry run (create but don't email patches)")
send.add_argument('-r', '--in-reply-to', type=str, action='store',
help="Message ID that this series is in reply to")
-send.add_argument('-t', '--ignore-bad-tags', action='store_true',
- default=False,
- help='Ignore bad tags / aliases (default=warn)')
-send.add_argument('-T', '--thread', action='store_true', dest='thread',
+send.add_argument('-t', '--ignore-bad-tags', action=BooleanOptionalAction,
+ default=False, help='Ignore bad tags / aliases')
+send.add_argument('-T', '--thread', action=BooleanOptionalAction,
dest='thread',
default=False, help='Create patches as a single thread')
send.add_argument('--cc-cmd', dest='cc_cmd', type=str, action='store',
default=None, help='Output cc list for patch file (used by git)')
-send.add_argument('--no-binary', action='store_true', dest='ignore_binary',
- default=False,
- help="Do not output contents of changes in binary files")
-send.add_argument('--no-check', action='store_false', dest='check_patch',
+send.add_argument('--binary',
[PATCH v2 3/6] patman: Don't look at sys.argv when parsing settings
If you call the parser and tell it to parse but don't pass arguments
in then it will default to looking at sys.argv. This isn't really what
was intended and seems to have some side effects. Let's not do it.
NOTE: to see some of the side effects, note that this patch breaks
"patman -c1" if you don't have the patch ("patman: Fix implicit
command inserting") before it.
Signed-off-by: Douglas Anderson
Tested-by: Brian Norris
Reviewed-by: Brian Norris
---
(no changes since v1)
tools/patman/settings.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 5eefe3d1f55e..92d82d5e8682 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -248,7 +248,7 @@ def _UpdateDefaults(main_parser, config):
# Collect the defaults from each parser
for parser in parsers:
-pdefs = parser.parse_known_args()[0]
+pdefs = parser.parse_known_args([])[0]
defaults = dict(vars(pdefs))
# Go through the settings and collect defaults
--
2.37.0.rc0.161.g10f37bed90-goog
[PATCH v2 2/6] patman: Fix implicit command inserting
The logic to insert an implicit command has always been a bit broken
but it was masked by another bug fixed in the patch ("patman: Don't
look at sys.argv when parsing settings"). Specifically, imagine that
you're just calling patman like this:
patman -c1
After the parse_known_args() command then the "-c1" will have been
parsed and we'll have no command. The "rest" variable will be an empty
list. Going into the logic you can see that nargs = 0. The implicit
insertion of send ideally would create an argument list of:
['-c1', 'send']
...but it doesn't because argv[:-0] is the same as argv[:0] and that's
an empty list.
Let's fix this little glitch.
Signed-off-by: Douglas Anderson
Tested-by: Brian Norris
Reviewed-by: Brian Norris
---
(no changes since v1)
tools/patman/main.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/patman/main.py b/tools/patman/main.py
index 2a2ac4570931..336f4e439aa9 100755
--- a/tools/patman/main.py
+++ b/tools/patman/main.py
@@ -120,7 +120,9 @@ else:
# No command, so insert it after the known arguments and before the ones
# that presumably relate to the 'send' subcommand
nargs = len(rest)
-argv = argv[:-nargs] + ['send'] + rest
+if nargs:
+argv = argv[:-nargs]
+argv = argv + ['send'] + rest
args = parser.parse_args(argv)
if __name__ != "__main__":
--
2.37.0.rc0.161.g10f37bed90-goog
[PATCH v2 1/6] patman: Fix updating argument defaults from settings
Ever since commit 4600767d294d ("patman: Refactor how the default
subcommand works"), when I use patman on the Linux tree I get grumbles
about unknown tags. This is because the Linux default making
process_tags be False wasn't working anymore.
It appears that the comment claiming that the defaults propagates
through all subparsers no longer works for some reason.
We're already looking at all the subparsers anyway. Let's just update
each one.
Fixes: 4600767d294d ("patman: Refactor how the default subcommand works")
Signed-off-by: Douglas Anderson
Tested-by: Brian Norris
Reviewed-by: Brian Norris
---
(no changes since v1)
tools/patman/settings.py | 41 +---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 7c2b5c196c06..5eefe3d1f55e 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -244,28 +244,31 @@ def _UpdateDefaults(main_parser, config):
if isinstance(action, argparse._SubParsersAction)
for _, subparser in action.choices.items()]
+unknown_settings = set(name for name, val in config.items('settings'))
+
# Collect the defaults from each parser
-defaults = {}
for parser in parsers:
pdefs = parser.parse_known_args()[0]
-defaults.update(vars(pdefs))
-
-# Go through the settings and collect defaults
-for name, val in config.items('settings'):
-if name in defaults:
-default_val = defaults[name]
-if isinstance(default_val, bool):
-val = config.getboolean('settings', name)
-elif isinstance(default_val, int):
-val = config.getint('settings', name)
-elif isinstance(default_val, str):
-val = config.get('settings', name)
-defaults[name] = val
-else:
-print("WARNING: Unknown setting %s" % name)
-
-# Set all the defaults (this propagates through all subparsers)
-main_parser.set_defaults(**defaults)
+defaults = dict(vars(pdefs))
+
+# Go through the settings and collect defaults
+for name, val in config.items('settings'):
+if name in defaults:
+default_val = defaults[name]
+if isinstance(default_val, bool):
+val = config.getboolean('settings', name)
+elif isinstance(default_val, int):
+val = config.getint('settings', name)
+elif isinstance(default_val, str):
+val = config.get('settings', name)
+defaults[name] = val
+unknown_settings.discard(name)
+
+# Set all the defaults
+parser.set_defaults(**defaults)
+
+for name in sorted(unknown_settings):
+print("WARNING: Unknown setting %s" % name)
def _ReadAliasFile(fname):
"""Read in the U-Boot git alias file if it exists.
--
2.37.0.rc0.161.g10f37bed90-goog
[PATCH v2 0/6] patman: Small fixes plus remove --no-tree from checkpatch for linux
The whole point of this series is really to make it so that when we're using patman for sending Linux patches that we don't pass "--no-tree" to checkpatch. While doing that, though, I found a number of bugs including an explanation about why recent version of patman have been yelling about "tags" when used with Linux even though Linux is supposed to have "process_tags" defaulted to False. Changes in v2: - Fix doc string for --ignore-bad-tags - Make comment about parsing three times less nonsensical. Douglas Anderson (6): patman: Fix updating argument defaults from settings patman: Fix implicit command inserting patman: Don't look at sys.argv when parsing settings patman: Make most bool arguments BooleanOptionalAction patman: By default don't pass "--no-tree" to checkpatch for linux patman: Take project defaults into account for --help tools/patman/checkpatch.py | 11 -- tools/patman/control.py| 7 ++-- tools/patman/main.py | 77 ++ tools/patman/settings.py | 46 --- 4 files changed, 80 insertions(+), 61 deletions(-) -- 2.37.0.rc0.161.g10f37bed90-goog
Re: Pull request: SoCFPGA changes for commit 05dcb5be507a
On Fri, Jul 01, 2022 at 09:00:38AM +, Chee, Tien Fong wrote: > Hi Tom, > > Please pull the SoCFPGA changes as shown in below. > > Thanks. > > Best regards, > Tien Fong > > > The following changes since commit 05dcb5be507a0580a0fc57dd363c632ac4a6b3c4: > > mtd: mxs_nand_spl: fix nand_command protocol violation (2022-06-29 09:26:44 > -0400) > > are available in the Git repository at: > > https://github.com/tienfong/uboot_mainline.git > ef5ba2cef4a08b68caaa9215fcac142d3025bbf7 > > for you to fetch changes up to ef5ba2cef4a08b68caaa9215fcac142d3025bbf7: > > drivers: clk: Update license for Intel N5X device (2022-07-01 15:00:39 > +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-rockchip-20220630
On Fri, Jul 01, 2022 at 10:05:55AM +0800, Kever Yang wrote: > Hi Tom, > > Sorry for lat sending this bunch of fix on rockchip platform. > Please pull the rockchip fixes if possible: > - Fix for rk3328 nonopi-r2s boot env; > - Fix for rk8xx pmic boot on power plug-in; > - Fix for tee.bin support in fit image; > - rk3288 board dts update or fix; > - Some rk3399 board fix; > > Gitlab ci: > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/12562 > > Thanks, > - Kever > > The following changes since commit a063429c17616007f6c48aaa293683402ae6ea56: > > Merge branch '2022-06-28-assorted-fixes' (2022-06-28 17:02:25 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20220630 > > for you to fetch changes up to fce1e9bba263fb5e3e589fdc5c2321f733e3de81: > > rockchip: pinebook-pro: sync PBP dtb to 5.18 (2022-06-29 11:43:05 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-amlogic-20220701
On Fri, Jul 01, 2022 at 10:19:25AM +0200, Neil Armstrong wrote: > > Hi Tom, > > Here's changes for next release: > - search dtb for meson-axg-usb-ctrl on board axg > > The CI job is at > https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/12587 > > Thanks, > Neil > > The following changes since commit 6f00b97d7e5760d92566317dde6c4b9224790827: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2022-05-20 > 22:07:56 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-20220701 > > for you to fetch changes up to fdc55a6ba8309b688c9db6c3cf3f70ad7034c147: > > meson: axg: search dtb for meson-axg-usb-ctrl on board axg (2022-05-23 > 10:40:01 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL next] u-boot-at91-2022.10-a
On Thu, Jun 30, 2022 at 02:50:29PM +, eugen.hris...@microchip.com wrote: > Hello Tom, > > > Please pull tag u-boot-at91-2022.10-a , the first set of new at91 > features for the next cycle 2022.10 . > > This feature set includes mostly fixes and alignments: DT alignment with > Linux for sama7g5, removal of invalid eeprom compatibles, removal of > extra debug_uart_init calls for all at91 boards, support for pio4 driver > pioE bank, and other minor fixes and enhancements for sam9x60 and > sama5d2_icp boards. > > Thanks, > Eugen > > The following changes since commit ea82ed8c2eaee0a0f7dee31016aaee4ce88e9ea7: > >Merge branch '2022-06-27-add-armv8-sha1-sha256-support' into next > (2022-06-27 13:39:19 -0400) > > are available in the Git repository at: > >https://source.denx.de/u-boot/custodians/u-boot-at91.git > tags/u-boot-at91-2022.10-a > > for you to fetch changes up to c1cadac7933cbc3f81e9096843b8751baff9: > >gpio: atmel_pio4: add support for PIO_PORTE (2022-06-30 15:49:00 +0300) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/Makefile.lib: add -D__U_BOOT__ to dtc_cpp_flags
On Fri, Jul 01, 2022 at 09:27:59AM +0200, Rasmus Villemoes wrote: > When trying to use the exact same device tree source to build the dtbs > used with U-Boot and linux, one often runs into various problems. For > example, files under include/dt-bindings/ might not be completely in > sync, so some #defines are available in linux but not in U-Boot. > > It's also possible that there are nodes/hardware one simply doesn't > need or want to describe to U-Boot, e.g. to reduce the size of the > .dtb (for SPL, there's already the whole fdtgrep machinery to deal > with that, but not for U-Boot proper), or configuration settings like > watchdog timeout one wants to make different between linux and U-Boot. > > So in order to allow such tweaks, add an explicit define of the macro > __U_BOOT__. Since U-Boot includes linux/kconfig.h (and defines > __ASSEMBLY__ to make that work) while linux doesn't, one could also > use __ASSEMBLY__ or just about any known-to-be-defined CONFIG_* macro > as a proxy, but it's much more readable, maintainable and robust if > one's .dts has "ifdef __U_BOOT__" rather than "ifdef __ASSEMBLY__". > > Signed-off-by: Rasmus Villemoes > --- > scripts/Makefile.lib | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 3db2550085..4183767a62 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -190,6 +190,7 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc >\ >-I$(srctree)/arch/$(ARCH)/dts/include \ >-I$(srctree)/include\ >-D__ASSEMBLY__ \ > + -D__U_BOOT__\ >-undef -D__DTS__ > > # Finds the multi-part object the current object will be linked into Since this implies to me using __U_BOOT__ in the main dts file itself, we need to bring this up on devicetree-spec. Otherwise, we could just use the -u-boot.dtsi to remove nodes/properties, yes? And then bindings needing to be re-synced is something to incentivize, from my point of view, initially at least. -- Tom signature.asc Description: PGP signature
Re: [PATCH RFC v3 11/11] ci: world_build: test: Add requirements.txt
On 15/06/2022 09:48, Neha Malcom Francis wrote:
> To avoid ModuleNotFoundErrors during World Build in CI tests, add
> installation of test/py/requirements.txt to .azure-pipelines.yml
>
> Signed-off-by: Neha Malcom Francis
> ---
> .azure-pipelines.yml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index ad540ea635..0fd57f59f4 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -551,6 +551,7 @@ stages:
>EOF
>cat << "EOF" >> build.sh
>if [[ "${BUILDMAN}" != "" ]]; then
> + pip install -r test/py/requirements.txt
>ret=0;
>tools/buildman/buildman -o /tmp -P -E -W ${BUILDMAN}
> ${OVERRIDE} || ret=$?;
>if [[ $ret -ne 0 ]]; then
Reviewed-by: Alper Nebi Yasak
Re: [PATCH RFC v3 10/11] ti: dtsi: j721e: Use binman to package tispl.bin
On 15/06/2022 09:48, Neha Malcom Francis wrote:
> tispl.bin must be packaged (with ATF, OPTEE, DM and A72 SPL) for J721E.
> Binman picks up and packages entries according to the
> description given in the device tree.
>
> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman
> node. It is included by k3-j721e-common-proc-board-u-boot.dtsi
>
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
> .../k3-j721e-common-proc-board-u-boot.dtsi| 1 +
> board/ti/j721e/Kconfig| 1 +
> 3 files changed, 88 insertions(+)
> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>
> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> new file mode 100644
> index 00..beb3424bb9
> --- /dev/null
> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +
> +#include
> +
> +#ifdef CONFIG_ARM64
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> + {
> + tispl {
> + filename = "tispl.bin";
Empty lines for this file as well.
> + fit {
> + description = "FIT IMAGE";
> + #address-cells = <1>;
> + images {
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + os = "arm-trusted-firmware";
> + load = ;
> + entry = ;
> + atf-bl31 {
> + };
> + };
> + tee {
> + description = "OPTEE";
> + type = "tee";
> + arch = "arm64";
> + compression = "none";
> + os = "tee";
> + load = <0x9e80>;
> + entry = <0x9e80>;
> + tee-os {
> + };
> + };
> + dm {
> + description = "DM binary";
> + type = "firmware";
> + arch = "arm32";
> + compression = "none";
> + os = "DM";
> + load = <0x8900>;
> + entry = <0x8900>;
> + ti-dm {
> + };
> + };
> + spl {
> + description = "SPL (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + entry = ;
> + u-boot-spl-nodtb {
> + };
> + };
> + k3-j721e-common-proc-board.dtb {
> + description =
> "k3-j721e-common-proc-board";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename =
> "spl/dts/k3-j721e-common-proc-board.dtb";
Indentation here, but it could be a u-boot-spl-dtb entry instead. Or,
there's a @fdt-SEQ mechanism to include files based on CONFIG_OF_LIST,
which you might want to look at.
> + };
> + };
> + };
> + configurations {
> + default = "conf";
> + conf {
> + description =
> "k3-j721e-common-proc-board";
> + firmware = "atf";
> + loadables = "tee", "dm", "spl";
> + fdt = "k3-j721e-common-proc-board.dtb";
> + };
> + };
> +
Re: [PATCH RFC v3 09/11] ti: dtsi: j721e: Use binman to package sysfw.itb and tiboot3.bin
On 15/06/2022 09:48, Neha Malcom Francis wrote:
> By providing entries in the binman node of the device tree, binman will
> be able to find and package board config binary artifacts generated by
> TIBoardConfig with sysfw.bin and generate the final image sysfw.itb.
>
> k3-j721e-r5-binman.dtsi has been introduced for R5 specific binman node.
> It can be then be include by files that require it like
> k3-j721e-r5-common-proc-board-u-boot.dtsi.
>
> Signed-off-by: Tarun Sahu
> [n-fran...@ti.com: prepared patch for upstreaming]
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-j721e-r5-binman.dtsi | 88 +++
> .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 1 +
> board/ti/j721e/Kconfig| 1 +
> 3 files changed, 90 insertions(+)
> create mode 100644 arch/arm/dts/k3-j721e-r5-binman.dtsi
>
> diff --git a/arch/arm/dts/k3-j721e-r5-binman.dtsi
> b/arch/arm/dts/k3-j721e-r5-binman.dtsi
> new file mode 100644
> index 00..e3aeefb08f
> --- /dev/null
> +++ b/arch/arm/dts/k3-j721e-r5-binman.dtsi
> @@ -0,0 +1,88 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +
> +#include
> +
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> + {
> + tiboot3 {
> + filename = "tiboot3.bin";
> + ti-x509-cert {
> + content = <>;
> + core = <16>;
> + load = ;
> + };
> + image1: u-boot-spl {
> + no-expanded;
> + };
Please put empty lines between properties and nodes, and between each
node. Labels could be u_boot_spl, ti_sysfw instead of image1/2.
> + };
> + binary {
> + filename = "sysfw.bin";
> + ti-x509-cert {
> + content = <>;
> + core = <0>;
> + load = <0x004>;
> + };
> + image2: ti-sysfw {
> + };
> + };
> + itb {
> + filename = "sysfw.itb";
> + fit {
> + description = "SYSFW and Config Fragments";
> + #address-cells = <1>;
> + images {
> + sysfw.bin {
> + description = "sysfw";
> + type = "firmware";
> + arch = "arm";
> + compression = "none";
> + blob {
> + filename = "sysfw.bin";
> + };
> + };
I dislike having the meaningless 'blob' and 'blob-ext' as node names.
Having the extension doesn't make much sense to me for the FIT entry,
but I like it for the blob itself:
sysfw {
description = "sysfw";
type = "firmware";
arch = "arm";
compression = "none";
sysfw.bin {
filename = "sysfw.bin";
type = "blob";
};
};
> + board-cfg.bin {
> + description = "board-cfg";
> + type = "firmware";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename = "board-cfg.bin";
> + };
> + };
> + pm-cfg.bin {
> + description = "pm-cfg";
> + type = "firmware";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename = "pm-cfg.bin";
> + };
> + };
> + rm-cfg.bin {
> + description = "rm-cfg";
> + type = "firmware";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename = "rm-cfg.bin";
> + };
> + };
> + sec-cfg.bin {
> + description = "sec-cfg";
> + type = "firmware";
> + arch = "arm";
> + compression = "none";
> +
Re: [PATCH RFC v3 05/11] ti: etype: x509: Add etype for x509 certificate for K3 devices
On 15/06/2022 09:47, Neha Malcom Francis wrote: > K3 devices requires x509 certificate to be added as header of bootloader > binaries that allows ROM to validate the integrity of the image. Etype > that generates a TI x509 certificate is added. > > Currently this etype is scaled for J721E. For J721E, tiboot3.bin > requires the x509 certificate binary to be prepended to the R5 SPL. > > Signed-off-by: Neha Malcom Francis > --- > test/py/requirements.txt| 1 + > tools/binman/entries.rst| 15 ++ > tools/binman/etype/ti_x509_cert.py | 241 > tools/binman/ftest.py | 6 + > tools/binman/test/232_x509_cert.dts | 18 +++ > 5 files changed, 281 insertions(+) > create mode 100644 tools/binman/etype/ti_x509_cert.py > create mode 100644 tools/binman/test/232_x509_cert.dts > > diff --git a/test/py/requirements.txt b/test/py/requirements.txt > index a91ba64563..add264bdaf 100644 > --- a/test/py/requirements.txt > +++ b/test/py/requirements.txt > @@ -11,6 +11,7 @@ packaging==19.2 > pbr==5.4.3 > pluggy==0.13.0 > py==1.10.0 > +pycryptodome==3.14.1 You don't need this if you use Cryptodome instead of Crypto. It's the same thing as pycryptodomex below. > pycryptodomex==3.9.8 > pyelftools==0.27 > pygit2==0.28.2 > diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst > index b6915ef12e..e7757b3e06 100644 > --- a/tools/binman/entries.rst > +++ b/tools/binman/entries.rst > @@ -1890,6 +1890,21 @@ and kernel are genuine. > > > > +Entry: ti-x509-cert: Texas Instruments x509 certificate for K3 devices > + > + > +Properties / Entry arguments: > +- content: Phandle of binary to sign > +- output: Name of the final output file > +- key_file: File with key inside it. If not provided, script > generates RSA degenerate key > +- core: Target core ID on which image would be running > +- load: Target load address of the binary in hex > + > +Output files: > +- certificate.bin: Signed certificate binary > + > + > + > Entry: x86-reset16: x86 16-bit reset code for U-Boot > > > diff --git a/tools/binman/etype/ti_x509_cert.py > b/tools/binman/etype/ti_x509_cert.py > new file mode 100644 > index 00..b79946c0b9 > --- /dev/null > +++ b/tools/binman/etype/ti_x509_cert.py > @@ -0,0 +1,241 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (c) 2018 Google, Inc > +# Written by Simon Glass > +# > + > +# Support for a TI x509 certificate for signing K3 devices > + > +from subprocess import Popen, PIPE Anything you want to run should normally be a bintool that provides a pythonic wrapper for it, see tools/binman/btool for examples. But if that's too much, openssl calls must at least use the patman.command functions instead. > +from sys import stderr, stdout Don't mess with stderr, stdout. See tools/patman/command for things you can use to run commands and capture their output. > +import os > +import tempfile > + > +from Crypto.PublicKey import RSA Prefer Cryptodome instead. > + > +from binman.etype.collection import Entry_collection > +from dtoc import fdt_util > +from patman import tools > + > + > +class Entry_ti_x509_cert(Entry_collection): > +"""An entry which contains an x509 certificate binary signed with 1024 > bit RSA key > + > +Properties / Entry arguments: > +- content: Phandle of binary to generate signature for > +- key_file: File with key inside it. If not provided, script > generates RSA degenrate key > +- core: Target core ID on which image would be running > +- load: Target load address of the binary in hex > + > +Output files: > +- certificate.bin: Signed certificate binary""" > + > +def __init__(self, section, etype, node): > +super().__init__(section, etype, node) > +self.key_file = fdt_util.GetString(self._node, 'key-file', "") > +self.core = fdt_util.GetInt(self._node, 'core', 0) > +self.load_addr = fdt_util.GetInt(self._node, 'load', 0x41c0) These should actually be in ReadNode(). You should set things to None-like values here to show which attributes will exist, and also do it for attributes set later in other methods. > +self.cert = fdt_util.GetString(self._node, 'cert', 'certificate.bin') This looks unused. > + > +# temporary directory for intermediate files > +self.outdir = tempfile.mkdtemp(prefix='binman.x509.') For now, omit this and put the outputs in the build directory. See below for an example. (We should eventually reorganize intermediate files, but it should be done by generic helpers that all entries can use). > + > +def ReadNode(self): > +super().ReadNode() > +if self.key_file == "": > +self.key_int_file = os.path.join(self.outdir, 'eckey.pem') > +self.GenerateDegenKey() > +
Re: [PATCH RFC v3 04/11] ti: etype: dm: Add entry type for TI DM
On 15/06/2022 09:47, Neha Malcom Francis wrote:
> K3 devices introduces the concept of centralized power, resource and
> security management to System Firmware. This is to overcome challenges
> by the traditional approach that implements system control functions on
> each of the processing units.
>
> The software interface for System Firmware is split into TIFS and DM. DM
TIFS (TI Foundational Security), I assume.
> (Device Manager) is responsible for resource and power management from
> secure and non-secure hosts. This additional binary is necessary for
> specific platforms' ROM boot images and is to be packaged into tispl.bin
>
> Add an entry for DM. The entry can be used for the packaging of
> tispl.bin by binman along with ATF and TEE.
>
> Signed-off-by: Neha Malcom Francis
> ---
> Makefile| 1 +
> tools/binman/entries.rst| 10 ++
> tools/binman/etype/ti_dm.py | 23 +++
> tools/binman/ftest.py | 7 +++
> tools/binman/test/225_ti_dm.dts | 13 +
> 5 files changed, 54 insertions(+)
> create mode 100644 tools/binman/etype/ti_dm.py
> create mode 100644 tools/binman/test/225_ti_dm.dts
Reviewed-by: Alper Nebi Yasak
Same minor issues as the previous patch.
> diff --git a/Makefile b/Makefile
> index d20d264c53..9b29e8e6a2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1342,6 +1342,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
> $(BINMAN_DEBUG),-D) \
> $(foreach f,$(BINMAN_INDIRS),-I $(f)) \
> -a atf-bl31-path=${BL31} \
> -a tee-os-path=${TEE} \
> + -a ti-dm-path=${DM} \
> -a opensbi-path=${OPENSBI} \
> -a default-dt=$(default_dt) \
> -a scp-path=$(SCP) \
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index 9fc5c48c35..b6915ef12e 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -1214,6 +1214,16 @@ devices.
>
>
>
> +Entry: ti-dm: Texas Instruments Device Manager (DM) blob
> +-
> +
> +Properties / Entry arguments:
> +- ti-dm-path: Filename of file to read into the entry, typically dm.bin
> +
> +This entry holds the device manager responsible for resource and power
> management in K3 devices.
> +
> +
> +
> Entry: section: Entry that contains other entries
> -
>
> diff --git a/tools/binman/etype/ti_dm.py b/tools/binman/etype/ti_dm.py
> new file mode 100644
> index 00..4203fff36e
> --- /dev/null
> +++ b/tools/binman/etype/ti_dm.py
> @@ -0,0 +1,23 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +#
> +# Entry type for TI Device Manager
> +
> +import os
> +
> +from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
> +
> +
> +class Entry_ti_dm(Entry_blob_named_by_arg):
> +"""Entry containing a Texas Instruments Device Manager (DM)
> +
> +Properties / Entry arguments:
> +- ti-dm-path: Filename of file to read into the entry, typically
> dm.bin
> +
> +This entry holds the device manager responsible for resource and power
> management
> +in K3 devices.
> +"""
> +
> +def __init__(self, section, etype, node):
> +super().__init__(section, etype, node, 'ti-dm')
> +self.external = True
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 671d083c54..3709b68297 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -85,6 +85,7 @@ FSP_S_DATA= b'fsp_s'
> FSP_T_DATA= b'fsp_t'
> ATF_BL31_DATA = b'bl31'
> TEE_OS_DATA = b'this is some tee OS data'
> +TI_DM_DATA= b'tidmtidm'
> ATF_BL2U_DATA = b'bl2u'
> OPENSBI_DATA = b'opensbi'
> TI_SYSFW_DATA = b'sysfw'
> @@ -194,6 +195,7 @@ class TestFunctional(unittest.TestCase):
> TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
> TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
> TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
> +TestFunctional._MakeInputFile('dm.bin', TI_DM_DATA)
> TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
> TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
> TestFunctional._MakeInputFile('sysfw.bin', TI_SYSFW_DATA)
> @@ -5307,6 +5309,11 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> data = self._DoReadFile('222_tee_os.dts')
> self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
>
> +def testPackTiDm(self):
> +"""Test that an image with a TI DM binary can be created"""
> +data = self._DoReadFile('225_ti_dm.dts')
> +self.assertEqual(TI_DM_DATA, data[:len(TI_DM_DATA)])
> +
> def testFitFdtOper(self):
> """Check handling
Re: [PATCH RFC v3 03/11] ti: etype: sysfw: Add entry type for sysfw
On 15/06/2022 09:47, Neha Malcom Francis wrote:
> For K3 devices that require a sysfw image, add entry for SYSFW. It can
> contain system firmware image that can be packaged into sysfw.itb by
> binman.
>
> Signed-off-by: Tarun Sahu
> [n-fran...@ti.com: added tests for addition of etype]
> Signed-off-by: Neha Malcom Francis
> ---
> Makefile | 1 +
> tools/binman/entries.rst | 11 +++
> tools/binman/etype/ti_sysfw.py | 28
> tools/binman/ftest.py | 7 +++
> tools/binman/test/232_ti_sysfw.dts | 13 +
> 5 files changed, 60 insertions(+)
> create mode 100644 tools/binman/etype/ti_sysfw.py
> create mode 100644 tools/binman/test/232_ti_sysfw.dts
Reviewed-by: Alper Nebi Yasak
Minor points below.
> diff --git a/Makefile b/Makefile
> index 61927f8918..d20d264c53 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1345,6 +1345,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
> $(BINMAN_DEBUG),-D) \
> -a opensbi-path=${OPENSBI} \
> -a default-dt=$(default_dt) \
> -a scp-path=$(SCP) \
> + -a ti-sysfw-path=$(SYSFW) \
> -a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
> -a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
> -a spl-dtb=$(CONFIG_SPL_OF_REAL) \
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index ae4305c99e..9fc5c48c35 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -1203,6 +1203,17 @@ This entry holds firmware for an external
> platform-specific coprocessor.
>
>
>
> +Entry: ti-sysfw: Texas Instruments System Firmware (SYSFW) blob
> +
> +
> +Properties / Entry arguments:
> +- ti-sysfw-path: Filename of file to read into the entry, typically
> sysfw.bin
> +
> +This entry contains system firmware necessary for booting of K3 architecture
> +devices.
> +
> +
> +
Regenerate these with `binman entry-docs >tools/binman/entries.rst` for
all your new entry types.
> Entry: section: Entry that contains other entries
> -
>
> diff --git a/tools/binman/etype/ti_sysfw.py b/tools/binman/etype/ti_sysfw.py
> new file mode 100644
> index 00..5b5b307030
> --- /dev/null
> +++ b/tools/binman/etype/ti_sysfw.py
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +#
> +# Entry type module for TI SYSFW binary blob
> +#
> +
> +import os
> +import struct
> +import sys
> +import zlib
> +
> +from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
> +from dtoc import fdt_util
> +from patman import tools
Remove unused imports.
> +
> +
> +class Entry_ti_sysfw(Entry_blob_named_by_arg):
> +"""Entry containing Texas Instruments System Firmware (SYSFW) blob
> +
> +Properties / Entry arguments:
> +- ti-sysfw-path: Filename of file to read into the entry, typically
> sysfw.bin
> +
> +This entry contains system firmware necessary for booting of K3
> architecture devices.
> +"""
> +
> +def __init__(self, section, etype, node):
> +super().__init__(section, etype, node, 'ti-sysfw')
> +self.external = True
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index b5cf549703..671d083c54 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -87,6 +87,7 @@ ATF_BL31_DATA = b'bl31'
> TEE_OS_DATA = b'this is some tee OS data'
> ATF_BL2U_DATA = b'bl2u'
> OPENSBI_DATA = b'opensbi'
> +TI_SYSFW_DATA = b'sysfw'
> SCP_DATA = b'scp'
> TEST_FDT1_DATA= b'fdt1'
> TEST_FDT2_DATA= b'test-fdt2'
> @@ -195,6 +196,7 @@ class TestFunctional(unittest.TestCase):
> TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
> TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
> TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
> +TestFunctional._MakeInputFile('sysfw.bin', TI_SYSFW_DATA)
> TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
>
> # Add a few .dtb files for testing
> @@ -5529,6 +5531,11 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> """Test an image with a pre-load header with an invalid key"""
> with self.assertRaises(ValueError) as e:
> data = self._DoReadFile('231_pre_load_invalid_key.dts')
> +
> +def testPackTiSysfw(self):
> +"""Test that an image with a SYSFW binary can be created"""
> +data = self._DoReadFile('232_ti_sysfw.dts')
> +self.assertEqual(TI_SYSFW_DATA, data[:len(TI_SYSFW_DATA)])
>
Add new tests to the end of the file, renumber the dts files to be unique.
> def _CheckSafeUniqueNames(self, *images):
> """Check all
Re: [PATCH RFC v3 02/11] ti: tools: config: Add board config class to generate config binaries
On 15/06/2022 09:47, Neha Malcom Francis wrote:
> For validating config files and generating binary config artifacts, here
> board specific config class is added.
>
> Add function cfgBinaryGen() in tibcfg_gen.py. It uses TIBoardConfig
> class to load given schema and config files in YAML, validate them and
> generate binaries.
>
> Signed-off-by: Tarun Sahu
> [n-fran...@ti.com: prepared patch for upstreaming]
> Signed-off-by: Neha Malcom Francis
> ---
> test/py/requirements.txt | 1 +
> tools/tibcfg_gen.py | 114 +++
> 2 files changed, 115 insertions(+)
> create mode 100644 tools/tibcfg_gen.py
>
> diff --git a/test/py/requirements.txt b/test/py/requirements.txt
> index 33c5c0bbc4..a91ba64563 100644
> --- a/test/py/requirements.txt
> +++ b/test/py/requirements.txt
> @@ -4,6 +4,7 @@ coverage==4.5.4
> extras==1.0.0
> fixtures==3.0.0
> importlib-metadata==0.23
> +jsonschema==4.0.0
> linecache2==1.0.0
> more-itertools==7.2.0
> packaging==19.2
> diff --git a/tools/tibcfg_gen.py b/tools/tibcfg_gen.py
> new file mode 100644
> index 00..e5fa2690c8
> --- /dev/null
> +++ b/tools/tibcfg_gen.py
> @@ -0,0 +1,114 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +#
> +# TI Board Configuration Class for Schema Validation and Binary Generation
> +#
> +
> +import os
> +import getopt
> +import sys
> +
> +import yaml
> +
> +from jsonschema import validate
> +
> +
> +class TIBoardConfig:
> +
> +""" Texas Instruments Board Configuration File"""
> +
> +def __init__(self, file, schema, data_rules=""):
> +"""Load a YAML configuration file and YAML schema
> +
> +Validation of the config file against the schema is also done."""
> +with open(file, 'r') as f:
> +self.file_yaml = yaml.safe_load(f)
> +with open(schema, 'r') as sch:
> +self.schema_yaml = yaml.safe_load(sch)
> +self.data_rules = data_rules
> +try:
> +validate(self.file_yaml, self.schema_yaml)
> +except Exception as e:
> +print(e)
Don't catch the exception here, so that we never have a non-validated
TIBoardConfig object. Instead, catch it in cfgBinaryGen() below to
report the validation error.
> +
> +def _convert_to_byte_chunk(self, val, data_type):
> +"""Convert value into byte array"""
> +size = 0
> +if(data_type == "#/definitions/u8"):
> +size = 1
> +elif(data_type == "#/definitions/u16"):
> +size = 2
> +elif(data_type == "#/definitions/u32"):
> +size = 4
Parentheses are unnecessary for these as well.
> +else:
> +raise Exception("Data type not present in definitions")
> +if type(val) == int:
> +br = val.to_bytes(size, byteorder="little")
> +return br
> +
> +def _compile_yaml(self, schema_yaml, file_yaml):
> +"""Convert YAML file into byte array based on YAML schema"""
> +br = bytearray()
> +for key in file_yaml.keys():
> +node = file_yaml[key]
> +node_schema = schema_yaml['properties'][key]
> +node_type = node_schema.get('type')
> +if not 'type' in node_schema:
> +br += self._convert_to_byte_chunk(node,
> + node_schema.get('$ref'))
> +elif node_type == 'object':
> +br += self._compile_yaml(node_schema, node)
> +elif node_type == 'array':
> +for item in node:
> +if not isinstance(item, dict):
> +br += self._convert_to_byte_chunk(
> +item,
> schema_yaml['properties'][key]['items']["$ref"])
> +else:
> +br += self._compile_yaml(node_schema.get('items'),
> item)
> +return br
> +
> +def generate_binaries(self, out_path=""):
> +"""Generate config binary artifacts from the loaded YAML
> configuration file"""
> +if not os.path.isdir(out_path):
> +os.mkdir(out_path)
> +for key in self.file_yaml.keys():
> +node = self.file_yaml[key]
> +node_schema = self.schema_yaml['properties'][key]
> +br = self._compile_yaml(node_schema, node)
> +path = os.path.join(out_path, key + ".bin")
> +with open(path, 'wb') as cfg:
> +cfg.write(br)
> +
> +def delete_binaries(self, out_path=""):
> +"""Delete generated binaries"""
> +if os.path.isdir(out_path):
> +for key in self.file_yaml.keys():
> +path = os.path.join(out_path, key + ".bin")
> +if os.path.isfile(path):
> +os.remove(path)
> +
> +
> +def cfgBinaryGen():
> +"""Generate config binaries from YAML config file and YAML schema
> +Arguments:
> +
Re: [PATCH RFC v3 00/11] Integration of tiboot3.bin, sysfw.itb and
On 15/06/2022 09:47, Neha Malcom Francis wrote: > [...] > > Neha Malcom Francis (11): > j721e_evm: schema: yaml: Add general schema and J721E board config > files > ti: tools: config: Add board config class to generate config binaries > ti: etype: sysfw: Add entry type for sysfw > ti: etype: dm: Add entry type for TI DM > ti: etype: x509: Add etype for x509 certificate for K3 devices These three would be better as 'binman: ...", sorry for not being clear about that. > ti: sysfw: Add support for packaging sysfw.itb > ti: j721e: Exclude makefile tiboot3.bin target for J721E > ti: j721e: Exclude makefile tispl.bin target for J721E > ti: dtsi: j721e: Use binman to package sysfw.itb and tiboot3.bin > ti: dtsi: j721e: Use binman to package tispl.bin > ci: world_build: test: Add requirements.txt
[PATCH] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
arch/arm/dts/rk3399.dtsi has a node
usb_host0_ehci: usb@fe38 {
compatible = "generic-ehci";
with clocks:
clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
<>;
The first 2 refer to nodes with class UCLASS_CLK, but
has class UCLASS_PHY.
u2phy0: usb2phy@e450 {
compatible = "rockchip,rk3399-usb2phy";
Since clk_get_bulk() only looks for devices with UCLASS_CLK,
it fails with -ENODEV and then ehci_usb_probe() aborts.
The consequence is peripherals connected to a USB 2 port (e.g. in a
Rock Pi 4 the white port, nearer the edge) not being detected.
They're detected if CONFIG_USB_OHCI_GENERIC is selected in Kconfig,
because ohci_usb_probe() does not abort when one clk_get_by_index()
fails, but then they work in USB 1 mode,.
rk3399.dtsi comes from linux and the u2phy0 was added[1] to the clock
list in:
commit b5d1c57299734f5b54035ef2e61706b83041f20c
Author: William wu
Date: Wed Dec 21 18:41:05 2016 +0800
arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399
We found that the suspend process was blocked when it run into
ehci/ohci module due to clk-480m of usb2-phy was disabled.
[...]
Suspend concerns don't apply to U-Boot, and the problem with U-Boot
failing to probe EHCI doesn't apply to linux, because in linux
rockchip_usb2phy_clk480m_register makes u2phy0 a proper clock provider
when called by rockchip_usb2phy_probe().
So I can think of a few alternative solutions:
1- Change ehci_usb_probe() to make it more similar to
ohci_usb_probe(), and survive failure to get one clock. Looks a
little harder, and I don't know whether it could break something if
it ignored a clock that was important for something else than
suspend.
2- Change rk3399.dtsi effecttively reverting the linux commit
b5d1c57299734f5b54035ef2e61706b83041f20c. This dealigns the .dtsi
from linux and seems fragile at the next synchronisation.
3- Change the clock list in rk3399-u-boot.dtsi or somewhere else.
This survives .dts* sync but may survive "too much" and miss some
change from linux that we might want.
4- Enable CONFIG_USB_OHCI_GENERIC and use the ports in USB 1 mode.
This would need to be made for all boards using rk3399. In a
simple test reading one file from USB storage it gave 769.5 KiB/s
instead of 20.5 MiB/s with solution 2.
5- Trying to replicate linux and have usb2phy somehow provide a clk,
or have a separate clock device for usb2phy in addition to the phy
device. I just can't seem to imagine how to achieve this with the
U-Boot driver model, maybe because of my limited familiarity with
it.
This patch is option 3. Looked like the simplest and most performant.
But it might not be what's wanted, so comments wellcome.
Link: [1] https://lkml.kernel.org/lkml/1731551.Q6cHK6n5ZM@phil/T/
Cc: Simon Glass
Cc: Philipp Tomsich
Cc: Kever Yang
Cc: Lukasz Majewski
Cc: Sean Anderson
Cc: Marek Vasut
Signed-off-by: Xavier Drudis Ferran
---
arch/arm/dts/rk3399-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 716b9a433a..63c7b10405 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -147,3 +147,11 @@
{
u-boot,dm-pre-reloc;
};
+
+_host0_ehci {
+ clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>;
+};
+
+_host1_ehci {
+ clocks = < HCLK_HOST1>, < HCLK_HOST1_ARB>;
+};
--
2.20.1
Re: [PATCH] sunxi-nand: fix the PIO instead of DMA implementation
Am Fr., 1. Juli 2022 um 11:57 Uhr schrieb Andre Przywara < andre.przyw...@arm.com>: Hi Andre, > On Thu, 30 Jun 2022 23:30:50 +0200 > Markus Hoffrogge wrote: > > Hi Markus, > > > as this patch has been delegated to you, > > thanks for sending the patch, and for the heads up, looks > like we should add that file somewhere into MAINTAINERS. > (And please keep people on CC:, to not split up the thread on the > list). > > > I would like to mention, that this patch is superseding > > the patch > https://patchwork.ozlabs.org/project/uboot/patch/20220330204543.3790-1-macroalph...@gmail.com/ > > raised by Chris Morgan. > > So from a first look at it, I like this version better, mostly because > it's much shorter ;-) > > That being said, I tried to stay away from raw NAND as much as possible in > the past, and thought that our support in U-Boot is very minimal. So can > someone please enlighten me about the status: > - AFAIK raw NAND is only supported on the C.H.I.P. Pro, because this is > one the few devices featuring SLC NAND. I guess the main feature of raw > NAND is that it's cheaper, so using SLC instead of MLC kind of defeats the > main purpose of it. > - Is there a separate SPL story? As in: loading U-Boot proper from NAND > when the BROM loaded the SPL from there? IIUC read disturbance makes even > that part non-trivial. > - Because of the absence of SLC in modern devices, and the prevalence of > eMMC, raw NAND was rarely used on modern devices (>= H3). So did we ever > support that? My understanding was that the NAND controller itself is > fairly similar (is it?), but the MLC problem would still persist. > I fully agree, but the MLC problem has been adressed already a while ago by introducing the slc_mode on mainline Kernel for MLC with the NAND page pairing approach by Boris Brezillon and Richard Weinberger. See https://bootlin.com/pub/conferences/2016/elce/brezillon-ubi-mlc/ubi-mlc.pdf. It will half the usable size of the NAND, but I guess it is perfect and best approach for getting the MLC used in a most robust way. So this at least should be sufficient for using it for some minimal rootfs for boot configuration or initial startup OS for configuring and e.g. attaching/initializing a SATA SSD. Main motivation is to get the board NAND booting not to rely on a SD card, since this is weak in rough or industrial environments and the SDCard slot should be free for other usage. The OS will be on a SATA SSD in most usecases anyway. - How do you actually write to the NAND? It seems like even reading is > non-trivial, so is this done from U-Boot, (BSP?) Linux, or using vendor > tools, probably via FEL? > Writing to MLC NAND I am doing as follows on a Cubietruck (CT): 1. I create an Armbian image for SDCARD for the CT with a currently user patched CT UBoot and kernel config with the following: (I will provide an appropriate patch for this separately later) Note: This CT config extension does not break the SDCard boot. - enabling SUNXI NAND and SUNXI NAND SPL Extended config on UBoot configs/Cubietruck_defconfig: [...append to current CT config] CONFIG_NAND=y CONFIG_NAND_SUNXI=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y # # SPL loader NAND offsets according to Kernel # .dts mtd partitions: # CONFIG_SYS_NAND_U_BOOT_OFFS=0x40 CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x60 # # CT specific Hynix MLC NAND 27UCG8T2ATR-BC config: # CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH=64 CONFIG_NAND_SUNXI_SPL_ECC_SIZE=1024 CONFIG_NAND_SUNXI_SPL_USABLE_PAGE_SIZE=4096 CONFIG_SYS_NAND_PAGE_SIZE=8192 CONFIG_SYS_NAND_OOBSIZE=640 CONFIG_SYS_NAND_BLOCK_SIZE=0x20 [EOF] - overlay .dts for the kernel to add nfc node with SPL and UBoot NAND partitions 2MB each on NAND blocksize boundaries providing: - /dev/mtd0 - SPL - /dev/mtd1 - SPL-backup - /dev/mtd2 - UBoot - /dev/mtd3 - UBoot-backup - /dev/mtd4 - UBI (UBI in slc_mode for rootfs - later use) This rootfs yould more or less hold the kernel image and other scripts relevant for booring to be more flexible for updates on the kernel and the boot environment scripts. - add mtd-utils package for the OS - I will provide a github link for my Armbian fork soon its not yet commited 2. Plugin SDCard and boot CT with this image from SD card - copy UBoot SPL ./spl/sunxi-spl-with-ecc.bin to the CT - copy UBoot image u-boot-dtb.img to the CT 3. Logon to CT and run on CT: - erase /dev/mtd0 - sudo flash_erase /dev/mtd0 0 0 - write the SUNXI UBoot SPL ./spl/sunxi-spl-with-ecc.bin to /dev/mtd0 - sudo nandwrite -o -n /dev/mtd0 sunxi-spl-with-ecc.bin - erase /dev/mtd2 - sudo flash_erase /dev/mtd2 0 0 - write u-boot-dtb.img to /dev/mtd2 - sudo nandwrite -p /dev/mtd2
[PATCH v1 3/3] configs: am62x_evm_r5: Add support for ESM
Enable ESM driver for AM62x in R5 SPL/u-boot build. Signed-off-by: Julien Panis --- configs/am62x_evm_r5_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig index 2e340cd6f416..64cd4a4acd09 100644 --- a/configs/am62x_evm_r5_defconfig +++ b/configs/am62x_evm_r5_defconfig @@ -96,3 +96,6 @@ CONFIG_SPL_TIMER=y CONFIG_OMAP_TIMER=y CONFIG_LIB_RATIONAL=y CONFIG_SPL_LIB_RATIONAL=y +CONFIG_ESM_K3=y +CONFIG_SPL_MISC=y +CONFIG_SPL_DRIVERS_MISC=y -- 2.25.1
[PATCH v1 2/3] arm64: mach-k3: am625_init: Probe ESM nodes
On AM62x devices, main ESM error event outputs can be routed to
MCU ESM as inputs. So, two ESM device nodes are expected in the
device tree : one for main ESM and another one for MCU ESM.
MCU ESM error output can trigger the reset logic to reset
the device when CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is
set to '0'.
Signed-off-by: Julien Panis
---
arch/arm/mach-k3/am625_init.c | 23 +++
arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 0d9525992bb0..dfd95b8053b5 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -64,6 +64,15 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(PADCFG_MMR1_BASE, 1);
}
+static __maybe_unused void enable_mcu_esm_reset(void)
+{
+ /* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z to '0' (low active)
*/
+ u32 stat = readl(CTRLMMR_MCU_RST_CTRL);
+
+ stat &= RST_CTRL_ESM_ERROR_RST_EN_Z_MASK;
+ writel(stat, CTRLMMR_MCU_RST_CTRL);
+}
+
void board_init_f(ulong dummy)
{
struct udevice *dev;
@@ -142,6 +151,20 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
+ if (IS_ENABLED(CONFIG_ESM_K3)) {
+ /* Probe/configure ESM0 */
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@42",
);
+ if (ret)
+ printf("esm main init failed: %d\n", ret);
+
+ /* Probe/configure MCUESM */
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@410",
);
+ if (ret)
+ printf("esm mcu init failed: %d\n", ret);
+
+ enable_mcu_esm_reset();
+ }
+
#if defined(CONFIG_K3_AM64_DDRSS)
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h
b/arch/arm/mach-k3/include/mach/am62_hardware.h
index cfabd20cbd79..9118d052042a 100644
--- a/arch/arm/mach-k3/include/mach/am62_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
@@ -29,6 +29,7 @@
#define MAIN_DEVSTAT_BACKUP_BOOTMODE_SHIFT 10
#define MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_MASK BIT(13)
#define MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_SHIFT 13
+#define RST_CTRL_ESM_ERROR_RST_EN_Z_MASK (~BIT(17))
/* Primary Bootmode MMC Config macros */
#define MAIN_DEVSTAT_PRIMARY_MMC_PORT_MASK 0x4
@@ -67,6 +68,8 @@
#define MCU_CTRL_DEVICE_CLKOUT_32K_CTRL(MCU_CTRL_MMR0_BASE +
0x8058)
#define MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL(0x3)
+#define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE + 0x18170)
+
#define ROM_ENTENDED_BOOT_DATA_INFO0x43c3f1e0
/* Use Last 2K as Scratch pad */
--
2.25.1
[PATCH v1 1/3] arm64: dts: k3-am625-r5: Add support for ESM devices
Add main ESM and MCU ESM nodes to AM625-R5 device tree.
Signed-off-by: Julien Panis
---
arch/arm/dts/k3-am625-r5-sk.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 2691af40a145..54896937d270 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -78,6 +78,15 @@
ti,secure-host;
};
+_mcu {
+ mcu_esm: esm@410 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x410 0x0 0x1000>;
+ ti,esm-pins = <0>, <1>, <2>, <85>;
+ u-boot,dm-spl;
+ };
+};
+
_main {
sa3_secproxy: secproxy@4488 {
u-boot,dm-spl;
@@ -95,6 +104,13 @@
mbox-names = "tx", "rx", "boot_notify";
u-boot,dm-spl;
};
+
+ main_esm: esm@42 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x42 0x0 0x1000>;
+ ti,esm-pins = <160>, <161>, <162>, <163>, <177>, <178>;
+ u-boot,dm-spl;
+ };
};
_pmx0 {
--
2.25.1
[PATCH v1 0/3] AM62x ESM support
[ERRATUM] Patch sent previously with wrong subject prefix. I am sorry. This patch series adds support for AM62x ESM (Error Signaling Modules). The Error Signaling Module (ESM) aggregates events and errors from throughout the device into one location. It can signal interrupts to a processor to deal with an event, and manipulate an error pin to signal an external hardware that an error has occurred. Therefore an external controller is able to reset the device. Two ESM can be used : one for main domain devices and another one for MCU domain devices. Event outputs generated by main ESM can be routed to MCU ESM as inputs, and trigger MCU ESM generating its event outputs. Following are required in defconfig: CONFIG_ESM_K3=y CONFIG_SPL_MISC=y CONFIG_SPL_DRIVERS_MISC=y Julien Panis (3): arm64: dts: k3-am625-r5: Add support for ESM devices arm64: mach-k3: am625_init: Probe ESM nodes configs: am62x_evm_r5: Add support for ESM arch/arm/dts/k3-am625-r5-sk.dts | 16 + arch/arm/mach-k3/am625_init.c | 23 +++ arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++ configs/am62x_evm_r5_defconfig| 3 +++ 4 files changed, 45 insertions(+) -- 2.25.1
[tiU21.01 PATCH 3/3] configs: am62x_evm_r5: Add support for ESM
Enable ESM driver for AM62x in R5 SPL/u-boot build. Signed-off-by: Julien Panis --- configs/am62x_evm_r5_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig index 2e340cd6f416..64cd4a4acd09 100644 --- a/configs/am62x_evm_r5_defconfig +++ b/configs/am62x_evm_r5_defconfig @@ -96,3 +96,6 @@ CONFIG_SPL_TIMER=y CONFIG_OMAP_TIMER=y CONFIG_LIB_RATIONAL=y CONFIG_SPL_LIB_RATIONAL=y +CONFIG_ESM_K3=y +CONFIG_SPL_MISC=y +CONFIG_SPL_DRIVERS_MISC=y -- 2.25.1
[tiU21.01 PATCH 2/3] arm64: mach-k3: am625_init: Probe ESM nodes
On AM62x devices, main ESM error event outputs can be routed to
MCU ESM as inputs. So, two ESM device nodes are expected in the
device tree : one for main ESM and another one for MCU ESM.
MCU ESM error output can trigger the reset logic to reset
the device when CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is
set to '0'.
Signed-off-by: Julien Panis
---
arch/arm/mach-k3/am625_init.c | 23 +++
arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 0d9525992bb0..dfd95b8053b5 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -64,6 +64,15 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(PADCFG_MMR1_BASE, 1);
}
+static __maybe_unused void enable_mcu_esm_reset(void)
+{
+ /* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z to '0' (low active)
*/
+ u32 stat = readl(CTRLMMR_MCU_RST_CTRL);
+
+ stat &= RST_CTRL_ESM_ERROR_RST_EN_Z_MASK;
+ writel(stat, CTRLMMR_MCU_RST_CTRL);
+}
+
void board_init_f(ulong dummy)
{
struct udevice *dev;
@@ -142,6 +151,20 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
+ if (IS_ENABLED(CONFIG_ESM_K3)) {
+ /* Probe/configure ESM0 */
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@42",
);
+ if (ret)
+ printf("esm main init failed: %d\n", ret);
+
+ /* Probe/configure MCUESM */
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@410",
);
+ if (ret)
+ printf("esm mcu init failed: %d\n", ret);
+
+ enable_mcu_esm_reset();
+ }
+
#if defined(CONFIG_K3_AM64_DDRSS)
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h
b/arch/arm/mach-k3/include/mach/am62_hardware.h
index cfabd20cbd79..9118d052042a 100644
--- a/arch/arm/mach-k3/include/mach/am62_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
@@ -29,6 +29,7 @@
#define MAIN_DEVSTAT_BACKUP_BOOTMODE_SHIFT 10
#define MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_MASK BIT(13)
#define MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_SHIFT 13
+#define RST_CTRL_ESM_ERROR_RST_EN_Z_MASK (~BIT(17))
/* Primary Bootmode MMC Config macros */
#define MAIN_DEVSTAT_PRIMARY_MMC_PORT_MASK 0x4
@@ -67,6 +68,8 @@
#define MCU_CTRL_DEVICE_CLKOUT_32K_CTRL(MCU_CTRL_MMR0_BASE +
0x8058)
#define MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL(0x3)
+#define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE + 0x18170)
+
#define ROM_ENTENDED_BOOT_DATA_INFO0x43c3f1e0
/* Use Last 2K as Scratch pad */
--
2.25.1
[tiU21.01 PATCH 0/3] AM62x ESM support
This patch series adds support for AM62x ESM (Error Signaling Modules). The Error Signaling Module (ESM) aggregates events and errors from throughout the device into one location. It can signal interrupts to a processor to deal with an event, and manipulate an error pin to signal an external hardware that an error has occurred. Therefore an external controller is able to reset the device. Two ESM can be used : one for main domain devices and another one for MCU domain devices. Event outputs generated by main ESM can be routed to MCU ESM as inputs, and trigger MCU ESM generating its event outputs. Following are required in defconfig: CONFIG_ESM_K3=y CONFIG_SPL_MISC=y CONFIG_SPL_DRIVERS_MISC=y Julien Panis (3): arm64: dts: k3-am625-r5: Add support for ESM devices arm64: mach-k3: am625_init: Probe ESM nodes configs: am62x_evm_r5: Add support for ESM arch/arm/dts/k3-am625-r5-sk.dts | 16 + arch/arm/mach-k3/am625_init.c | 23 +++ arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++ configs/am62x_evm_r5_defconfig| 3 +++ 4 files changed, 45 insertions(+) -- 2.25.1
[tiU21.01 PATCH 1/3] arm64: dts: k3-am625-r5: Add support for ESM devices
Add main ESM and MCU ESM nodes to AM625-R5 device tree.
Signed-off-by: Julien Panis
---
arch/arm/dts/k3-am625-r5-sk.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 2691af40a145..54896937d270 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -78,6 +78,15 @@
ti,secure-host;
};
+_mcu {
+ mcu_esm: esm@410 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x410 0x0 0x1000>;
+ ti,esm-pins = <0>, <1>, <2>, <85>;
+ u-boot,dm-spl;
+ };
+};
+
_main {
sa3_secproxy: secproxy@4488 {
u-boot,dm-spl;
@@ -95,6 +104,13 @@
mbox-names = "tx", "rx", "boot_notify";
u-boot,dm-spl;
};
+
+ main_esm: esm@42 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x42 0x0 0x1000>;
+ ti,esm-pins = <160>, <161>, <162>, <163>, <177>, <178>;
+ u-boot,dm-spl;
+ };
};
_pmx0 {
--
2.25.1
Re: [PATCH] sunxi-nand: fix the PIO instead of DMA implementation
Hi Andre, as this patch has been delegated to you, I would like to mention, that this patch is superseding the patch https://patchwork.ozlabs.org/project/uboot/patch/20220330204543.3790-1-macroalph...@gmail.com/ raised by Chris Morgan. It should solve the issue in general and does not require to revert to the former DMA implementation. Kind regards Markus
Re: [PATCH v7 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash
On Thu, Mar 3, 2022 at 11:58 AM JaimeLiao wrote: > > Adding Macronix Octal flash for Octal DTR support. > > The octaflash series can be divided into the following types: > > MX25 series : Serial NOR Flash. > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) > LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation. > LW/UW series : Support simultaneous Read-while-Write operation in multiple >bank architecture. Read-while-write feature which means read >data one bank while another bank is programing or erasing. > > MX25LM : 3.0V Octal I/O > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > MX25UM : 1.8V Octal I/O > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf > > MX66LM : 3.0V Octal I/O with stacked die > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf > > MX66UM : 1.8V Octal I/O with stacked die > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf > > MX25LW : 3.0V Octal I/O with Read-while-Write > MX25UW : 1.8V Octal I/O with Read-while-Write > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die > > About LW/UW series, please contact us freely if you have any > questions. For adding Octal NOR Flash IDs, we have validated > each Flash on plateform zynq-picozed. > > As below are the SFDP table dump. > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id > c2943c > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer > macronix > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname > mx66uw2g345gx0 > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66uw2g345gx0 > zynq> hexdump mx66uw2g345gx0 > 000 4653 5044 0108 fd04 0700 1401 0040 ff00 > 010 0187 1c01 0090 ff00 000a 0801 0100 ff00 > 020 0005 0501 0120 ff00 0084 0201 0134 ff00 > 030 > 040 20e5 ff8a 7fff ff00 ff00 ff00 ff00 > 050 ffee ff00 ff00 200c d810 > 060 ff00 ff00 7987 0001 1284 e200 04cc 4667 > 070 b030 b030 bdf4 5cd5 ff00 1010 2000 > 080 237c 0048 > 090 4000 d10f f3ff d10f f3ff > 0a0 0500 9000 0500 b100 2b00 9500 2b00 9600 > 0b0 7172 b803 7172 b803 a390 8218 > 0c0 c000 9669 7172 9800 > 0d0 7172 b800 7172 9900 7172 9800 > 0e0 7172 f800 7172 9900 7172 f900 > 0f0 1501 d001 7172 d806 5086 > 100 0106 0002 0301 0200 > 110 0106 0672 0200 > 120 ee00 69c0 7272 7171 d800 f6f7 0a00 > 130 4514 8098 0643 001f dc21 > 140 > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id > c2853b > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer > macronix > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname > mx66lm1g45g > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66lm1g45g > zynq> hexdump mx66lm1g45g > 000 4653 5044 0108 fd04 0700 1401 0040 ff00 > 010 0187 1c01 0090 ff00 000a 0801 0100 ff00 > 020 0005 0501 0120 ff00 0084 0201 0134 ff00 > 030 > 040 20e5 ff8a 3fff ff00 ff00 ff00 ff00 > 050 ffee ff00 ff00 200c d810 > 060 ff00 ff00 6987 0001 1282 e200 02cc 3867 > 070 b030 b030 bdf4 5cd5 ff00 1010 2000 > 080 a37c 0048 > 090 4000 d10f f3ff d10f f3ff > 0a0 0500 9000 0500 b100 2b00 9500 2b00 9600 > 0b0 7172 b803 7172 b803 a390 8218 > 0c0 c000 9669 7172 9800 > 0d0 7172 b800 7172 9900 7172 9800 > 0e0 7172 f800 7172 9900 7172 f900 > 0f0 1501 d001 7172 d806 5086 > 100 0106 0002 0301 0200 > 110 0106 0672 0200 > 120 ee00 69c0 7272 7171 d800 f6f7 > 130 3514 001c 0643 000f dc21 > 140 > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id > c2853a > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer > macronix > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname > mx25lm51245g > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx25lm51245g > zynq> hexdump mx25lm51245g > 000 4653 5044 0108 fd04 0700 1401 0040 ff00 > 010 0187 1c01 0090 ff00 000a 0801 0100 ff00 > 020 0005 0501 0120 ff00 0084 0201 0134 ff00 > 030 > 040 20e5 ff8a 1fff ff00 ff00 ff00 ff00 > 050 ffee ff00 ff00 200c d810 > 060 ff00 ff00 7989 0001 128d e200 02cc 4467 > 070 b030 b030 bdf4
Re: [PATCH v1] spi: nuvoton: add NPCM PSPI controller driver
On Tue, May 31, 2022 at 3:44 PM Jim Liu wrote: > > Add Nuvoton NPCM BMC Peripheral SPI controller driver. > NPCM750 include two general-purpose SPI interface. > > Signed-off-by: Jim Liu > --- Reviewed-by: Jagan Teki
Re: [PATCH 1/3] ram: rk3399: Fix .set_rate_index() error handling
Hi Lee Jones,
On 2022/6/27 16:39, Lee Jones wrote:
On Tue, 21 Jun 2022, Lee Jones wrote:
Functions pointed to by this op pointer can return non-zero values
indicating an error. Ensure any error value is propagated back up the
call-chain.
Signed-off-by: Lee Jones
---
drivers/ram/rockchip/sdram_rk3399.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Weekly check-in:
Are these still on someone's radar, or would you like me to [RESEND]?
It would be better to add leading message "rockchip:" in the subject.
Thanks,
- Kever
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index c0a06dcaed..0af0fa9e7b 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -3005,7 +3005,9 @@ static int sdram_init(struct dram_info *dram,
params->base.stride = calculate_stride(params);
dram_all_config(dram, params);
- dram->ops->set_rate_index(dram, params);
+ ret = dram->ops->set_rate_index(dram, params);
+ if (ret)
+ return ret;
debug("Finish SDRAM initialization...\n");
return 0;
Re: [PATCH 3/3] ram: rk3399: Conduct memory training at 400MHz
On 2022/6/21 18:07, Lee Jones wrote:
Currently the default initialisation frequency is 50MHz. Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.
Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.
Link: https://lore.kernel.org/u-boot/yo4v3juehxtov...@google.com/
Suggested-by: YouMin Chen
Signed-off-by: Lee Jones
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/ram/rockchip/sdram_rk3399.c | 36 +
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index 34d6c93f95..b05c5925d5 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -85,7 +85,7 @@ struct sdram_rk3399_ops {
int (*data_training_first)(struct dram_info *dram, u32 channel, u8 rank,
struct rk3399_sdram_params *sdram);
int (*set_rate_index)(struct dram_info *dram,
- struct rk3399_sdram_params *params);
+ struct rk3399_sdram_params *params, u32 ctl_fn);
void (*modify_param)(const struct chan_info *chan,
struct rk3399_sdram_params *params);
struct rk3399_sdram_params *
@@ -1644,7 +1644,8 @@ static int data_training_first(struct dram_info *dram,
u32 channel, u8 rank,
}
static int switch_to_phy_index1(struct dram_info *dram,
- struct rk3399_sdram_params *params)
+ struct rk3399_sdram_params *params,
+ u32 unused)
{
u32 channel;
u32 *denali_phy;
@@ -2539,26 +2540,25 @@ static int lpddr4_set_ctl(struct dram_info *dram,
}
static int lpddr4_set_rate(struct dram_info *dram,
- struct rk3399_sdram_params *params)
+ struct rk3399_sdram_params *params,
+ u32 ctl_fn)
{
- u32 ctl_fn;
u32 phy_fn;
- for (ctl_fn = 0; ctl_fn < 2; ctl_fn++) {
- phy_fn = lpddr4_get_phy_fn(params, ctl_fn);
+ phy_fn = lpddr4_get_phy_fn(params, ctl_fn);
- lpddr4_set_phy(dram, params, phy_fn, _cfgs_lpddr4[ctl_fn]);
- lpddr4_set_ctl(dram, params, ctl_fn,
- dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
+ lpddr4_set_phy(dram, params, phy_fn, _cfgs_lpddr4[ctl_fn]);
+ lpddr4_set_ctl(dram, params, ctl_fn,
+ dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
- if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
- printf("%s: change freq to %dMHz %d, %d\n", __func__,
- dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
- ctl_fn, phy_fn);
- }
+ if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
+ printf("%s: change freq to %dMHz %d, %d\n", __func__,
+ dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
+ ctl_fn, phy_fn);
return 0;
}
+
#endif /* CONFIG_RAM_RK3399_LPDDR4 */
/* CS0,n=1
@@ -2955,6 +2955,12 @@ static int sdram_init(struct dram_info *dram,
params->ch[ch].cap_info.rank = rank;
}
+#if defined(CONFIG_RAM_RK3399_LPDDR4)
+ /* LPDDR4 needs to be trained at 400MHz */
+ lpddr4_set_rate(dram, params, 0);
+ params->base.ddr_freq = dfs_cfgs_lpddr4[0].base.ddr_freq / MHz;
+#endif
+
params->base.num_channels = 0;
for (channel = 0; channel < 2; channel++) {
const struct chan_info *chan = >chan[channel];
@@ -3005,7 +3011,7 @@ static int sdram_init(struct dram_info *dram,
params->base.stride = calculate_stride(params);
dram_all_config(dram, params);
- ret = dram->ops->set_rate_index(dram, params);
+ ret = dram->ops->set_rate_index(dram, params, 1);
if (ret)
return ret;
Re: [PATCH 2/3] ram: rk3399: Fix faulty frequency change reports
On 2022/6/21 18:07, Lee Jones wrote:
Frequency changes to 400MHz are presently reported as:
lpddr4_set_rate_0: change freq to 4 mhz 0, 1
This is obviously wrong by 6 orders of magnitude.
Ensure frequency changes are reported accurately.
Signed-off-by: Lee Jones
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/ram/rockchip/sdram_rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index 0af0fa9e7b..34d6c93f95 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -2552,8 +2552,8 @@ static int lpddr4_set_rate(struct dram_info *dram,
dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
- printf("%s: change freq to %d mhz %d, %d\n", __func__,
- dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq,
+ printf("%s: change freq to %dMHz %d, %d\n", __func__,
+ dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
ctl_fn, phy_fn);
}
Re: [PATCH 1/3] ram: rk3399: Fix .set_rate_index() error handling
On 2022/6/21 18:07, Lee Jones wrote:
Functions pointed to by this op pointer can return non-zero values
indicating an error. Ensure any error value is propagated back up the
call-chain.
Signed-off-by: Lee Jones
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/ram/rockchip/sdram_rk3399.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index c0a06dcaed..0af0fa9e7b 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -3005,7 +3005,9 @@ static int sdram_init(struct dram_info *dram,
params->base.stride = calculate_stride(params);
dram_all_config(dram, params);
- dram->ops->set_rate_index(dram, params);
+ ret = dram->ops->set_rate_index(dram, params);
+ if (ret)
+ return ret;
debug("Finish SDRAM initialization...\n");
return 0;
Re: [v4 07/12] spi-mem: Add dirmap API from Linux
On Tue, May 24, 2022 at 11:28 AM Chin-Ting Kuo
wrote:
>
> This adds the dirmap API originally introduced in Linux commit aa167f3
> ("spi: spi-mem: Add a new API to support direct mapping"). This also
> includes several follow-up patches and fixes.
>
> Changes from Linux include:
> * Added Kconfig option
> * Changed struct device to struct udevice
> * Changed struct spi_mem to struct spi_slave
>
> This patch is obtained from the following patch
> https://patchwork.ozlabs.org/project/uboot/patch/20210205043924.149504-3-sean...@gmail.com/
>
> Signed-off-by: Chin-Ting Kuo
> Signed-off-by: Sean Anderson
> Acked-by: Pratyush Yadav
> ---
> v2: Remove "#if CONFIG_SPI_DIRMAP" compile wrapper.
> v3: Fix a grammatical error in spi-mem.h.
>
> drivers/spi/Kconfig | 10 ++
> drivers/spi/spi-mem.c | 268 ++
> include/spi-mem.h | 79 +
> 3 files changed, 357 insertions(+)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index a616294910..297253714a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -40,6 +40,16 @@ config SPI_MEM
> This extension is meant to simplify interaction with SPI memories
> by providing an high-level interface to send memory-like commands.
>
> +config SPI_DIRMAP
Look like the following code is not part of this if construct, we need
that to build only when SPI_DIRMAP is defined otherwise it footprint
increase for non-DIRMAPs. Also please take care of unnecessary code
while copying from Linux and add SHA1 in the commit message.
Jagan.
Re: [v4 00/12] Add ASPEED SPI controller driver
On Tue, May 24, 2022 at 11:27 AM Chin-Ting Kuo wrote: > > This patch series aims to porting ASPEED FMC/SPI memory controller > driver with spi-mem interface. spi-mem dirmap framework is also > synchronized from Linux. These patches have been verified on both > AST2600 and AST2500 EVBs. > > Changes in v2: > - Separate defconfig files from the SPI driver patch. > - Use "if (CONFIG_IS_ENABLED(SPI_DIRMAP))" to wrap > spi_dirmap related functions. > - Add Winbond w25q512jv flash ID. > > Changes in v3: > - Get AHB bus clock frequency from the function parameter. > - Fix a grammatical error in spi-mem.h. > > Changes in v4: > - Fix bug when SPI_NOR_4B_OPCODES flag is set. > > Chin-Ting Kuo (12): > clk: aspeed: Get HCLK frequency support > pinctrl: aspeed: FWSPICS1 and SPI1CS1 pin support > spi: aspeed: Add ASPEED SPI controller driver > configs: aspeed: Enable SPI flash features > MAINTAINERS: Add ASPEED SPI driver file > arm: dts: aspeed: Update SPI flash node settings > spi-mem: Add dirmap API from Linux > mtd: spi-nor: Use spi-mem dirmap API > spi: aspeed: SPI dirmap read support > configs: aspeed: Enable CONFIG_SPI_DIRMAP > mtd: spi-nor-ids: Add Winbond W25Q512JV ID > spi: aspeed: Fix bug when SPI_NOR_4B_OPCODES flag is set Sperate series for spi changes would really make it easier for review. please send it. Jagan.
Re: [v4 05/12] MAINTAINERS: Add ASPEED SPI driver file
On Tue, May 24, 2022 at 11:28 AM Chin-Ting Kuo wrote: > > Add spi-aspeed.c file for ARM ASPEED. > > Signed-off-by: Chin-Ting Kuo > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 56be0bfad0..f2cd707eda 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -688,6 +688,13 @@ S: Maintained > F: drivers/pci/pcie_phytium.c > F: arch/arm/dts/phytium-durian.dts > > +ASPEED FMC SPI DRIVER > +M: Chin-Ting Kuo > +M: Cédric Le Goater > +R: Aspeed BMC SW team > +S: Maintained > +F: drivers/spi/spi-aspeed.c Squash this part of spi-aspeed.c driver patch
Re: [v4 04/12] configs: aspeed: Enable SPI flash features
On 7/1/22 11:28, Cédric Le Goater wrote: On 5/24/22 07:56, Chin-Ting Kuo wrote: - Enable ASPEED SPI controller driver. - Enable SPI flash memory configurations. - Enable configurations for SPI flash manufacturers supported on both ASPEED AST2500 and AST2600 AVL. Signed-off-by: Chin-Ting Kuo --- configs/evb-ast2500_defconfig | 13 + configs/evb-ast2600_defconfig | 13 + 2 files changed, 26 insertions(+) diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig index 2371cc2742..fd04fe5a60 100644 --- a/configs/evb-ast2500_defconfig +++ b/configs/evb-ast2500_defconfig @@ -35,6 +35,16 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_ASPEED=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ASPEED=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_ISSI=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y +CONFIG_SPI_FLASH_WINBOND=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y CONFIG_FTGMAC100=y @@ -44,6 +54,9 @@ CONFIG_RAM=y CONFIG_DM_RESET=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_SPI_ASPEED=y CONFIG_SYSRESET=y CONFIG_TIMER=y CONFIG_WDT=y This is breaking boot on the AST2500 evb (QEMU) . I haven't found why yet. You might want to take a look. The resulting binary is too big for the flash layout we use on OpenBMC. C.
[PATCH] ARC: HSDK: permit to build out-of-tree
When building with out of tree source, make fail with:
uboot bin file not exists: /usr/src/uboot/u-boot.bin
This is due to obj files searched in srctree instead of objtree.
Fixes: 9ddcfef6d425 ("ARC: HSDK: Add tool and make target to generate bsp")
Signed-off-by: Corentin Labbe
---
board/synopsys/hsdk/config.mk | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/synopsys/hsdk/config.mk b/board/synopsys/hsdk/config.mk
index def944aad2..778a4283db 100644
--- a/board/synopsys/hsdk/config.mk
+++ b/board/synopsys/hsdk/config.mk
@@ -9,11 +9,11 @@ PLATFORM_CPPFLAGS += -mcpu=hs38_linux -mlittle-endian
-matomic -mll64 \
bsp-generate: u-boot u-boot.bin
$(Q)python3 $(srctree)/board/$(BOARDDIR)/headerize-hsdk.py \
- --arc-id 0x52 --image $(srctree)/u-boot.bin \
- --elf $(srctree)/u-boot
+ --arc-id 0x52 --image $(objtree)/u-boot.bin \
+ --elf $(objtree)/u-boot
$(Q)tools/mkimage -T script -C none -n 'uboot update script' \
- -d $(srctree)/u-boot-update.txt \
- $(srctree)/u-boot-update.scr &> /dev/null
+ -d $(objtree)/u-boot-update.txt \
+ $(objtree)/u-boot-update.scr &> /dev/null
endif
ifdef CONFIG_BOARD_HSDK_4XD
@@ -23,9 +23,9 @@ PLATFORM_CPPFLAGS += -mcpu=hs4x_rel31 -mlittle-endian
-matomic -mll64 \
bsp-generate: u-boot u-boot.bin
$(Q)python3 $(srctree)/board/$(BOARDDIR)/headerize-hsdk.py \
- --arc-id 0x54 --image $(srctree)/u-boot.bin \
- --elf $(srctree)/u-boot
+ --arc-id 0x54 --image $(objtree)/u-boot.bin \
+ --elf $(objtree)/u-boot
$(Q)tools/mkimage -T script -C none -n 'uboot update script' \
- -d $(srctree)/u-boot-update.txt \
- $(srctree)/u-boot-update.scr &> /dev/null
+ -d $(objtree)/u-boot-update.txt \
+ $(objtree)/u-boot-update.scr &> /dev/null
endif
--
2.35.1
net: designware: frequent network problem like CPU not owner of tx frame
Hello We have an HSDK board in kernelCI, and it fail often to do networking tasks. (getting image via tftp) Example: tftp 0x8200 2156673/tftp-deploy-l8y_ehqa/kernel/uImage Speed: 100, full duplex Using ethernet@f0008000 device TFTP from server 10.201.1.3; our IP address is 10.201.4.179 Filename '2156673/tftp-deploy-l8y_ehqa/kernel/uImage'. Load address: 0x8200 Loading: *␈CPU not owner of tx frame CPU not owner of tx frame CPU not owner of tx frame CPU not owner of tx frame ARP Retry count exceeded; starting again Memory error exception @ 0xfffe ECR:0x0001 RET:0xfffe BLINK: 0xbffb04e2 STAT32: 0x00080400 GP: 0x1003e000 r25: 0xbfd92ee0 BTA: 0xbffc5744 SP: 0xbfd92d60 FP: 0x LPS: 0x11f2 LPE: 0x11fa LPC: 0x r00: 0x r01: 0x r02: 0x r03: 0x r04: 0x r05: 0xbfd92d54 r06: 0xbffdc700 r07: 0x r08: 0xf0020028 r09: 0x1003e2b0 r10: 0x8000 r11: 0x000e r12: 0x0010 r13: 0xbfda6218 r14: 0xbfd933b8 r15: 0x0003 r16: 0x r17: 0x0003 r18: 0xbffeff90 r19: 0x r20: 0xbfd949c8 r21: 0x r22: 0x r23: 0x r24: 0x Resetting CPU ... ### ERROR ### Please RESET the board ### tftp 0x8200 2156279/tftp-deploy-o6vloihf/kernel/uImage Speed: 100, full duplex Using ethernet@f0008000 device TFTP from server 10.201.1.3; our IP address is 10.201.3.203 Filename '2156279/tftp-deploy-o6vloihf/kernel/uImage'. Load address: 0x8200 Loading: *␈ ARP Retry count exceeded; starting again tftp 0x8200 2155981/tftp-deploy-wm6qiwhy/kernel/uImage Speed: 100, full duplex Using ethernet@f0008000 device TFTP from server 10.201.1.3; our IP address is 10.201.4.197 Filename '2155981/tftp-deploy-wm6qiwhy/kernel/uImage'. Load address: 0x8200 Loading: *␈CPU not owner of tx frame CPU not owner of tx frame [...] (lot of CPU not owner of tx frame) CPU not owner of tx frame ARP Retry count exceeded; starting again I tried to update uboot until 2022.04, without any change. Regards
Re: [PATCH] sunxi-nand: fix the PIO instead of DMA implementation
On Thu, 30 Jun 2022 23:30:50 +0200 Markus Hoffrogge wrote: Hi Markus, > as this patch has been delegated to you, thanks for sending the patch, and for the heads up, looks like we should add that file somewhere into MAINTAINERS. (And please keep people on CC:, to not split up the thread on the list). > I would like to mention, that this patch is superseding > the patch > https://patchwork.ozlabs.org/project/uboot/patch/20220330204543.3790-1-macroalph...@gmail.com/ > raised by Chris Morgan. So from a first look at it, I like this version better, mostly because it's much shorter ;-) That being said, I tried to stay away from raw NAND as much as possible in the past, and thought that our support in U-Boot is very minimal. So can someone please enlighten me about the status: - AFAIK raw NAND is only supported on the C.H.I.P. Pro, because this is one the few devices featuring SLC NAND. I guess the main feature of raw NAND is that it's cheaper, so using SLC instead of MLC kind of defeats the main purpose of it. - Is there a separate SPL story? As in: loading U-Boot proper from NAND when the BROM loaded the SPL from there? IIUC read disturbance makes even that part non-trivial. - Because of the absence of SLC in modern devices, and the prevalence of eMMC, raw NAND was rarely used on modern devices (>= H3). So did we ever support that? My understanding was that the NAND controller itself is fairly similar (is it?), but the MLC problem would still persist. - How do you actually write to the NAND? It seems like even reading is non-trivial, so is this done from U-Boot, (BSP?) Linux, or using vendor tools, probably via FEL? I recently got an H6 TV box, which happens to use raw (MLC) NAND flash. I also inherited a Cubietruck, which is MLC as well. So can I use that storage, at least for the firmware? If yes, this should be documented somewhere, I guess? Or is it already? Cheers, Andre > It should solve the issue in general and does not require to > revert to the former DMA implementation. > > Kind regards > Markus
Re: [v4 12/12] spi: aspeed: Fix bug when SPI_NOR_4B_OPCODES flag is set
On 5/24/22 07:56, Chin-Ting Kuo wrote:
When SPI_NOR_4B_OPCODES flag is set for a specific flash
in spi_nor_ids[] table, EN4B command will not be issued and
4-byte dedicated commands will be used to access SPI flash.
Thus, instead of EN4B command, address length is more suitable
for deciding whether the controller should be set to 4-byte mode.
Signed-off-by: Chin-Ting Kuo
---
drivers/spi/spi-aspeed.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-aspeed.c b/drivers/spi/spi-aspeed.c
index e5e348eb7b..687ddc370b 100644
--- a/drivers/spi/spi-aspeed.c
+++ b/drivers/spi/spi-aspeed.c
@@ -504,10 +504,6 @@ static int aspeed_spi_exec_op_user_mode(struct spi_slave
*slave,
/* Restore controller setting. */
writel(flash->ce_ctrl_read, ctrl_reg);
- /* Set controller to 4-byte mode when flash is in 4-byte mode. */
- if (op->cmd.opcode == SPINOR_OP_EN4B)
- priv->info->set_4byte(bus, cs);
-
return 0;
}
This should be part of the patch adding the driver.
Thanks,
C.
@@ -561,6 +557,9 @@ static int aspeed_spi_dirmap_create(struct
spi_mem_dirmap_desc *desc)
plat->ctrl_base + REG_CE0_CTRL_REG + cs * 4);
priv->flashes[cs].ce_ctrl_read = reg_val;
+ if (op_tmpl.addr.nbytes == 4)
+ priv->info->set_4byte(bus, cs);
+
dev_dbg(dev, "read bus width: %d [0x%08x]\n",
op_tmpl.data.buswidth, priv->flashes[cs].ce_ctrl_read);
} else {
Re: [v4 11/12] mtd: spi-nor-ids: Add Winbond W25Q512JV ID
On 5/24/22 07:56, Chin-Ting Kuo wrote:
Add ID for Winbond W25Q512JV device which is supported
on AST2600 EVB by default.
Signed-off-by: Chin-Ting Kuo
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
drivers/mtd/spi/spi-nor-ids.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 7050ddc397..444affb5af 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -362,6 +362,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+ {
+ INFO("w25q512jv", 0xef4020, 0, 64 * 1024, 1024,
+SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
{
INFO("w25q01jv", 0xef4021, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
Re: [v4 06/12] arm: dts: aspeed: Update SPI flash node settings
On 5/24/22 07:56, Chin-Ting Kuo wrote:
For both AST2500 and AST2600, there are three
SPI controllers, FMC(Firmware Memory Controller),
SPI1 and SPI2. The clock source is HCLK. Following
is the basic information for ASPEED SPI controller.
AST2500:
- FMC:
CS number: 3
controller reg: 0x1e62 - 0x1e62
decoded address: 0x2000 - 0x2fff
- SPI1:
CS number: 2
controller reg: 0x1e63 - 0x1e630fff
decoded address: 0x3000 - 0x37ff
- SPI2:
CS number: 2
controller reg: 0x1e631000 - 0x1e631fff
decoded address: 0x3800 - 0x3fff
AST2600:
- FMC:
CS number: 3
controller reg: 0x1e62 - 0x1e62
decoded address: 0x2000 - 0x2fff
- SPI1:
CS number: 2
controller reg: 0x1e63 - 0x1e630fff
decoded address: 0x3000 - 0x3fff
- SPI2:
CS number: 3
controller reg: 0x1e631000 - 0x1e631fff
decoded address: 0x5000 - 0x5fff
Signed-off-by: Chin-Ting Kuo
I might be wrong for the comment I did on 'num-cs' in the patch adding
the driver. Joel, what's your opinion ? Hard coded in the driver or
a property in the DT ?
Thanks,
C.
---
arch/arm/dts/ast2500-evb.dts | 33 +
arch/arm/dts/ast2500.dtsi| 23 ---
arch/arm/dts/ast2600-evb.dts | 8
arch/arm/dts/ast2600.dtsi| 34 +++---
4 files changed, 68 insertions(+), 30 deletions(-)
diff --git a/arch/arm/dts/ast2500-evb.dts b/arch/arm/dts/ast2500-evb.dts
index 4796ed445f..c6b7675902 100644
--- a/arch/arm/dts/ast2500-evb.dts
+++ b/arch/arm/dts/ast2500-evb.dts
@@ -73,3 +73,36 @@
pinctrl-names = "default";
pinctrl-0 = <_sd2_default>;
};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_fwspics1_default>;
+
+ flash@0 {
+ status = "okay";
+ spi-max-frequency = <5000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+
+ flash@1 {
+ status = "okay";
+ spi-max-frequency = <5000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_spi1cs1_default>;
+
+ flash@0 {
+ status = "okay";
+ spi-max-frequency = <5000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+};
diff --git a/arch/arm/dts/ast2500.dtsi b/arch/arm/dts/ast2500.dtsi
index ee66ef6704..d78a53aeb7 100644
--- a/arch/arm/dts/ast2500.dtsi
+++ b/arch/arm/dts/ast2500.dtsi
@@ -57,23 +57,26 @@
ranges;
fmc: flash-controller@1e62 {
- reg = < 0x1e62 0xc4
- 0x2000 0x1000 >;
+ reg = <0x1e62 0xc4>, <0x2000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-fmc";
+ clocks = < ASPEED_CLK_AHB>;
+ num-cs = <3>;
status = "disabled";
- interrupts = <19>;
+
flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
status = "disabled";
};
+
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
status = "disabled";
};
+
flash@2 {
reg = < 2 >;
compatible = "jedec,spi-nor";
@@ -82,17 +85,20 @@
};
spi1: flash-controller@1e63 {
- reg = < 0x1e63 0xc4
- 0x3000 0x0800 >;
+ reg = <0x1e63 0xc4>, <0x3000 0x0800>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-spi";
+ clocks = < ASPEED_CLK_AHB>;
+ num-cs = <2>;
status = "disabled";
+
flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
status = "disabled";
};
+
flash@1 {
reg = < 1 >;
compatible = "jedec,spi-nor";
@@ -101,17 +107,20 @@
};
spi2: flash-controller@1e631000 {
- reg = < 0x1e631000 0xc4
-
Re: [v4 07/12] spi-mem: Add dirmap API from Linux
On 5/24/22 07:56, Chin-Ting Kuo wrote:
This adds the dirmap API originally introduced in Linux commit aa167f3
("spi: spi-mem: Add a new API to support direct mapping"). This also
includes several follow-up patches and fixes.
Changes from Linux include:
* Added Kconfig option
* Changed struct device to struct udevice
* Changed struct spi_mem to struct spi_slave
This patch is obtained from the following patch
https://patchwork.ozlabs.org/project/uboot/patch/20210205043924.149504-3-sean...@gmail.com/
It has been sent long ago. Is there an issue with the backport from Linux ?
Is it the lack of drivers using it ?
Thanks,
C.
Signed-off-by: Chin-Ting Kuo
Signed-off-by: Sean Anderson
Acked-by: Pratyush Yadav
---
v2: Remove "#if CONFIG_SPI_DIRMAP" compile wrapper.
v3: Fix a grammatical error in spi-mem.h.
drivers/spi/Kconfig | 10 ++
drivers/spi/spi-mem.c | 268 ++
include/spi-mem.h | 79 +
3 files changed, 357 insertions(+)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a616294910..297253714a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -40,6 +40,16 @@ config SPI_MEM
This extension is meant to simplify interaction with SPI memories
by providing an high-level interface to send memory-like commands.
+config SPI_DIRMAP
+ bool "SPI direct mapping"
+ depends on SPI_MEM
+ help
+ Enable the SPI direct mapping API. Most modern SPI controllers can
+ directly map a SPI memory (or a portion of the SPI memory) in the CPU
+ address space. Most of the time this brings significant performance
+ improvements as it automates the whole process of sending SPI memory
+ operations every time a new region is accessed.
+
if DM_SPI
config ALTERA_SPI
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 9c1ede1b61..8e8995fc53 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#endif
#ifndef __UBOOT__
@@ -491,6 +493,272 @@ int spi_mem_adjust_op_size(struct spi_slave *slave,
struct spi_mem_op *op)
}
EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
+static ssize_t spi_mem_no_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf)
+{
+ struct spi_mem_op op = desc->info.op_tmpl;
+ int ret;
+
+ op.addr.val = desc->info.offset + offs;
+ op.data.buf.in = buf;
+ op.data.nbytes = len;
+ ret = spi_mem_adjust_op_size(desc->slave, );
+ if (ret)
+ return ret;
+
+ ret = spi_mem_exec_op(desc->slave, );
+ if (ret)
+ return ret;
+
+ return op.data.nbytes;
+}
+
+static ssize_t spi_mem_no_dirmap_write(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, const void *buf)
+{
+ struct spi_mem_op op = desc->info.op_tmpl;
+ int ret;
+
+ op.addr.val = desc->info.offset + offs;
+ op.data.buf.out = buf;
+ op.data.nbytes = len;
+ ret = spi_mem_adjust_op_size(desc->slave, );
+ if (ret)
+ return ret;
+
+ ret = spi_mem_exec_op(desc->slave, );
+ if (ret)
+ return ret;
+
+ return op.data.nbytes;
+}
+
+/**
+ * spi_mem_dirmap_create() - Create a direct mapping descriptor
+ * @mem: SPI mem device this direct mapping should be created for
+ * @info: direct mapping information
+ *
+ * This function is creating a direct mapping descriptor which can then be used
+ * to access the memory using spi_mem_dirmap_read() or spi_mem_dirmap_write().
+ * If the SPI controller driver does not support direct mapping, this function
+ * falls back to an implementation using spi_mem_exec_op(), so that the caller
+ * doesn't have to bother implementing a fallback on his own.
+ *
+ * Return: a valid pointer in case of success, and ERR_PTR() otherwise.
+ */
+struct spi_mem_dirmap_desc *
+spi_mem_dirmap_create(struct spi_slave *slave,
+ const struct spi_mem_dirmap_info *info)
+{
+ struct udevice *bus = slave->dev->parent;
+ struct dm_spi_ops *ops = spi_get_ops(bus);
+ struct spi_mem_dirmap_desc *desc;
+ int ret = -EOPNOTSUPP;
+
+ /* Make sure the number of address cycles is between 1 and 8 bytes. */
+ if (!info->op_tmpl.addr.nbytes || info->op_tmpl.addr.nbytes > 8)
+ return ERR_PTR(-EINVAL);
+
+ /* data.dir should either be SPI_MEM_DATA_IN or SPI_MEM_DATA_OUT. */
+ if (info->op_tmpl.data.dir == SPI_MEM_NO_DATA)
+ return ERR_PTR(-EINVAL);
+
+ desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+ if (!desc)
+ return ERR_PTR(-ENOMEM);
+
+ desc->slave = slave;
+ desc->info = *info;
+ if (ops->mem_ops && ops->mem_ops->dirmap_create)
+ ret = ops->mem_ops->dirmap_create(desc);
+
+
Re: [v4 04/12] configs: aspeed: Enable SPI flash features
On 5/24/22 07:56, Chin-Ting Kuo wrote: - Enable ASPEED SPI controller driver. - Enable SPI flash memory configurations. - Enable configurations for SPI flash manufacturers supported on both ASPEED AST2500 and AST2600 AVL. Signed-off-by: Chin-Ting Kuo --- configs/evb-ast2500_defconfig | 13 + configs/evb-ast2600_defconfig | 13 + 2 files changed, 26 insertions(+) diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig index 2371cc2742..fd04fe5a60 100644 --- a/configs/evb-ast2500_defconfig +++ b/configs/evb-ast2500_defconfig @@ -35,6 +35,16 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_ASPEED=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ASPEED=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_ISSI=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y +CONFIG_SPI_FLASH_WINBOND=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y CONFIG_FTGMAC100=y @@ -44,6 +54,9 @@ CONFIG_RAM=y CONFIG_DM_RESET=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_SPI_ASPEED=y CONFIG_SYSRESET=y CONFIG_TIMER=y CONFIG_WDT=y This is breaking boot on the AST2500 evb (QEMU) . I haven't found why yet. You might want to take a look. Thanks, C. diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig index f84b723bbb..ccf63ec6d0 100644 --- a/configs/evb-ast2600_defconfig +++ b/configs/evb-ast2600_defconfig @@ -65,6 +65,16 @@ CONFIG_DM_I2C=y CONFIG_MISC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ASPEED=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_ISSI=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y +CONFIG_SPI_FLASH_WINBOND=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y CONFIG_DM_MDIO=y @@ -77,6 +87,9 @@ CONFIG_SPL_RAM=y CONFIG_DM_RESET=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_SPI_ASPEED=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_WDT=y
Re: [v4 03/12] spi: aspeed: Add ASPEED SPI controller driver
Hello Chin-Ting, On 5/24/22 07:56, Chin-Ting Kuo wrote: Add ASPEED BMC FMC/SPI memory controller driver with spi-mem interface for AST2500 and AST2600 platform. There are three SPI memory controllers embedded in an ASPEED SoC. - FMC: Named as Firmware Memory Controller. After AC on, MCU ROM fetches initial device boot image from FMC chip select(CS) 0. - SPI1: Play the role of a SPI Master controller. Or, there is a dedicated path for HOST(X86) to access its BIOS flash mounted under BMC. spi-aspeed.c implements the control sequence when SPI1 is a SPI master. - SPI2: It is a pure SPI flash controller. For most scenarios, flashes mounted under it are for pure storage purpose. ASPEED SPI controller supports 1-1-1, 1-1-2 and 1-1-4 SPI flash mode. Three types of command mode are supported, normal mode, command read/write mode and user mode. - Normal mode: Default mode. After power on, normal read command 03h or 13h is used to fetch boot image from SPI flash. - AST2500: Only 03h command can be used after power on or reset. - AST2600: If FMC04[6:4] is set, 13h command is used, otherwise, 03h command. The address length is decided by FMC04[2:0]. - Command mode: SPI controller can send command and address automatically when CPU read/write the related remapped or decoded address area. The command used by this mode can be configured by FMC10/14/18[23:16]. Also, the address length is decided by FMC04[2:0]. This mode will be implemented in the following patch series. - User mode: It is a traditional and pure SPI operation, where SPI transmission is controlled by CPU. It is the main mode in this patch. Each SPI controller in ASPEED SoC has its own decoded address mapping. Within each SPI controller decoded address, driver can assign a specific address region for each CS of a SPI controller. The decoded address cannot overlap to each other. With normal mode and command mode, the decoded address accessed by the CPU determines which CS is active. When user mode is adopted, the CS decoded address is a FIFO, CPU can send/receive any SPI transmission by accessing the related decoded address for the target CS. Signed-off-by: Chin-Ting Kuo I would split the patch furthermore to ease reading. 1 - Add basic support with default decoding ranges set for all possible CS, even without a device. WE only have USER mode for now. So it's not important to correctly set the ranges since we won't use them before direct mapping is introduced. They should not overlap, that's all. 2 - decoding range adjustments On that topic, we might want to take the simple DT approach with a "ranges" property defining the mapping windows of each CE. I think it is safer than trying to compute perfect ranges like on Linux. 3 - clock settings That should simply be the property defined in the DT --- v2: Remove defconfig files from this patch. drivers/spi/Kconfig | 8 + drivers/spi/Makefile | 1 + drivers/spi/spi-aspeed.c | 822 +++ 3 files changed, 831 insertions(+) create mode 100644 drivers/spi/spi-aspeed.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index a1e515cb2b..a616294910 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -387,6 +387,14 @@ config SANDBOX_SPI }; }; +config SPI_ASPEED + bool "ASPEED SPI controller driver" + depends on DM_SPI && SPI_MEM + default n + help + Enable ASPEED SPI controller driver for AST2500 + and AST2600 SoCs. + config SPI_SIFIVE bool "SiFive SPI driver" help diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 06e81b465b..36a4bd5dce 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -9,6 +9,7 @@ obj-y += spi-uclass.o obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o obj-$(CONFIG_SOFT_SPI) += soft_spi.o +obj-$(CONFIG_SPI_ASPEED) += spi-aspeed.o obj-$(CONFIG_SPI_MEM) += spi-mem.o obj-$(CONFIG_TI_QSPI) += ti_qspi.o obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o diff --git a/drivers/spi/spi-aspeed.c b/drivers/spi/spi-aspeed.c new file mode 100644 index 00..9574aff793 --- /dev/null +++ b/drivers/spi/spi-aspeed.c @@ -0,0 +1,822 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * ASPEED FMC/SPI Controller driver + * + * Copyright (c) 2022 ASPEED Corporation. + * Copyright (c) 2022 IBM Corporation. + * + * Author: + * Chin-Ting Kuo + * Cedric Le Goater + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include
Pull request: SoCFPGA changes for commit 05dcb5be507a
Hi Tom, Please pull the SoCFPGA changes as shown in below. Thanks. Best regards, Tien Fong The following changes since commit 05dcb5be507a0580a0fc57dd363c632ac4a6b3c4: mtd: mxs_nand_spl: fix nand_command protocol violation (2022-06-29 09:26:44 -0400) are available in the Git repository at: https://github.com/tienfong/uboot_mainline.git ef5ba2cef4a08b68caaa9215fcac142d3025bbf7 for you to fetch changes up to ef5ba2cef4a08b68caaa9215fcac142d3025bbf7: drivers: clk: Update license for Intel N5X device (2022-07-01 15:00:39 +0800) Paweł Anikiel (11): arm: dts: Add Mercury+ AA1 devicetrees arm: dts: Add Chameleonv3 handoff headers arm: dts: Add Chameleonv3 devicetrees board: Add Chameleonv3 board dir config: Add Chameleonv3 config misc: atsha204a: Increase wake delay by tWHI sysreset: socfpga: Use parent device for reading base address socfpga: arria10: Replace delays with busy waiting in cm_full_cfg socfpga: arria10: Improve bitstream loading speed socfpga: arria10: Wait for fifo empty after writing bitstream socfpga: arria10: Allow dcache_enable before relocation Teik Heng Chong (1): drivers: clk: Update license for Intel N5X device arch/arm/dts/Makefile | 2 + arch/arm/dts/socfpga_arria10_chameleonv3.dts | 90 arch/arm/dts/socfpga_arria10_chameleonv3_270_3-u-boot.dtsi | 8 ++ arch/arm/dts/socfpga_arria10_chameleonv3_270_3.dts | 5 + arch/arm/dts/socfpga_arria10_chameleonv3_270_3_handoff.h | 305 +++ arch/arm/dts/socfpga_arria10_chameleonv3_480_2-u-boot.dtsi | 8 ++ arch/arm/dts/socfpga_arria10_chameleonv3_480_2.dts | 5 + arch/arm/dts/socfpga_arria10_chameleonv3_480_2_handoff.h | 305 +++ arch/arm/dts/socfpga_arria10_mercury_aa1-u-boot.dtsi | 54 ++ arch/arm/dts/socfpga_arria10_mercury_aa1.dtsi | 72 + arch/arm/mach-socfpga/Kconfig | 7 ++ arch/arm/mach-socfpga/clock_manager_arria10.c | 31 -- arch/arm/mach-socfpga/misc_arria10.c | 26 + board/google/chameleonv3/Makefile | 5 + board/google/chameleonv3/board.c | 27 + board/google/chameleonv3/fpga.its | 28 + board/google/chameleonv3/fpga_early_io.its | 35 +++ board/google/chameleonv3/mercury_aa1.c | 43 board/google/chameleonv3/mercury_aa1.h | 12 +++ configs/socfpga_chameleonv3_defconfig | 29 ++ drivers/clk/altera/clk-mem-n5x.c | 4 +- drivers/clk/altera/clk-mem-n5x.h | 4 +- drivers/clk/altera/clk-n5x.c | 4 +- drivers/clk/altera/clk-n5x.h | 4 +- drivers/fpga/socfpga_arria10.c | 28 - drivers/misc/atsha204a-i2c.c | 5 +- drivers/sysreset/sysreset_socfpga.c| 2 +- include/configs/socfpga_chameleonv3.h | 44 28 files changed, 1170 insertions(+), 22 deletions(-) create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3.dts create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3_270_3-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3_270_3.dts create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3_270_3_handoff.h create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3_480_2-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3_480_2.dts create mode 100644 arch/arm/dts/socfpga_arria10_chameleonv3_480_2_handoff.h create mode 100644 arch/arm/dts/socfpga_arria10_mercury_aa1-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_arria10_mercury_aa1.dtsi create mode 100644 board/google/chameleonv3/Makefile create mode 100644 board/google/chameleonv3/board.c create mode 100644 board/google/chameleonv3/fpga.its create mode 100644 board/google/chameleonv3/fpga_early_io.its create mode 100644 board/google/chameleonv3/mercury_aa1.c create mode 100644 board/google/chameleonv3/mercury_aa1.h create mode 100644 configs/socfpga_chameleonv3_defconfig create mode 100644 include/configs/socfpga_chameleonv3.h
[GIT PULL] Please pull u-boot-amlogic-20220701
Hi Tom, Here's changes for next release: - search dtb for meson-axg-usb-ctrl on board axg The CI job is at https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/12587 Thanks, Neil The following changes since commit 6f00b97d7e5760d92566317dde6c4b9224790827: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2022-05-20 22:07:56 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20220701 for you to fetch changes up to fdc55a6ba8309b688c9db6c3cf3f70ad7034c147: meson: axg: search dtb for meson-axg-usb-ctrl on board axg (2022-05-23 10:40:01 +0200) - search dtb for meson-axg-usb-ctrl on board axg Sergei Antonov (1): meson: axg: search dtb for meson-axg-usb-ctrl on board axg arch/arm/mach-meson/board-axg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
RE: [PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, June 30, 2022 5:20 PM > > On 6/30/22 16:19, Johann Neuhauser wrote: > > PA13 and PA14 are used for USB power control and can't be used > > to enforce fastboot or stm32prog mode by pressing a button. > > > > Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied > > results in fastboot/stm32prog always starting, because PA13/PA14 are always > > low during boot. So drop the wrong trigger gpios definitions. > > > > Signed-off-by: Johann Neuhauser > > Those GPIOs also likely make no sense on DHCOM , right ? They would only make sense on the DHCOM PDK2, since this is the only mainline baseboard with user buttons available in U-Boot. > > Reviewed-by: Marek Vasut
[PATCH] scripts/Makefile.lib: add -D__U_BOOT__ to dtc_cpp_flags
When trying to use the exact same device tree source to build the dtbs used with U-Boot and linux, one often runs into various problems. For example, files under include/dt-bindings/ might not be completely in sync, so some #defines are available in linux but not in U-Boot. It's also possible that there are nodes/hardware one simply doesn't need or want to describe to U-Boot, e.g. to reduce the size of the .dtb (for SPL, there's already the whole fdtgrep machinery to deal with that, but not for U-Boot proper), or configuration settings like watchdog timeout one wants to make different between linux and U-Boot. So in order to allow such tweaks, add an explicit define of the macro __U_BOOT__. Since U-Boot includes linux/kconfig.h (and defines __ASSEMBLY__ to make that work) while linux doesn't, one could also use __ASSEMBLY__ or just about any known-to-be-defined CONFIG_* macro as a proxy, but it's much more readable, maintainable and robust if one's .dts has "ifdef __U_BOOT__" rather than "ifdef __ASSEMBLY__". Signed-off-by: Rasmus Villemoes --- scripts/Makefile.lib | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 3db2550085..4183767a62 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -190,6 +190,7 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include\ -D__ASSEMBLY__ \ +-D__U_BOOT__\ -undef -D__DTS__ # Finds the multi-part object the current object will be linked into -- 2.31.1
Re: [PATCH] serial: ns16550: Wait in debug_uart_init until tx buffer is empty
On 23.06.22 14:13, Pali Rohár wrote:
Commit d293759d55cc ("serial: ns16550: Add support for
SPL_DEBUG_UART_BASE") fixed support for setting correct early debug UART
base address in SPL.
But after this commit, output from Marvell A385 BootROM is truncated or
lost and not fully present on serial console.
Debugging this issue showed that BootROM just put bytes into UART HW output
buffer and does not wait until UART HW transmit all characters. U-Boot
ns16550 early debug is initialized very early and during its initialization
is resetting UART HW and flushing remaining transmit buffer (which still
contains BootROM output).
Fix this issue by waiting in init function prior resetting UART HW until
TxEmpty bit in UART Line Status Register is set. TxEmpty is set when all
remaining bytes from HW buffer are transmitted.
Signed-off-by: Pali Rohár
Just checking, do you need a "Fixes" tag as well here?
---
drivers/serial/ns16550.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 78bfe6281ce3..13418004e2b0 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -328,6 +328,8 @@ static inline void _debug_uart_init(void)
struct ns16550 *com_port = (struct ns16550
*)CONFIG_VAL(DEBUG_UART_BASE);
int baud_divisor;
+ while (!(serial_din(_port->lsr) & UART_LSR_TEMT));
I personally prefer the ";" in a separate line instead. Not sure what
the official coding style mentions to such constructs.
Anyways:
Reviewed-by: Stefan Roese
Thanks,
Stefan
