RE: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value
Hi Alban,
> -Original Message-
> From: U-Boot On Behalf Of Bedel, Alban
> Sent: Wednesday, June 30, 2021 7:08 PM
> To: Priyanka Jain ; Varun Sethi ;
> Wasim Khan (OSS)
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value
>
> On Wed, 2021-06-30 at 12:44 +, Wasim Khan (OSS) wrote:
> >
> >
> > > -Original Message-
> > > From: Bedel, Alban
> > > Sent: Wednesday, June 30, 2021 6:03 PM
> > > To: Priyanka Jain ; Varun Sethi <
> > > v.se...@nxp.com>; Wasim Khan ; Wasim Khan (OSS)
> > >
> > > Cc: u-boot@lists.denx.de
> > > Subject: Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default
> > > value
> > >
> > > On Wed, 2021-06-30 at 11:12 +, Priyanka Jain wrote:
> > > >
> > > > snip
> >
> > >
> > > * After issuing `env default -a ; saveenv' the board didn't boot
> > > anymore because `bootcmd` was then empty.
> >
> > This is not the case with latest u-boot code. 'env default -a' set
> > bootcmd to default one (run distro_bootcmd).
> > So, we are safe here.
> >
> >
> > >
> > > * If redundant env on eMMC was enabled `bootcmd` was then
> > > overwritten at every boot, preventing me from using a custom `bootcmd` at
> all.
> > >
> >
> > Priyanka, Alban
> > Can you help me to understand what does enabling 'redundant env' on
> > eMMC mean and how to enable it ?
>
> See env/Kconfig:
>
> config SYS_REDUNDAND_ENVIRONMENT
> bool "Enable redundant environment support"
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_FLASH || ENV_IS_IN_MMC
> || \
> ENV_IS_IN_NAND || ENV_IS_IN_SPI_FLASH || ENV_IS_IN_UBI
> help
> Normally, the environemt is stored in a single location. By
> selecting this option, you can then define where to hold a redundant
> copy of the environment data, so that there is a valid backup copy
> in
> case there is a power failure during a "saveenv" operation.
>
> When this option is enabled the internals of the env change significantly and
> the
> old code then always detected the env as being the default, erasing any
> previously user set value at every boot.
>
> But beside the fact that it didn't work properly with all configurations, the
> old
> code didn't really detect if the env was the default. When it worked, it
> detected
> the case where no valid env was stored and u-boot was using its internal in-
> memory defaults. That's why resetting the env to default would then break the
> boot.
>
> In my patch I replaced this logic by looking if `bootcmd` has the default
> value,
> which worked well as long as the default value was "unset". But as we see
> this is
> not a viable solution in the long run.
> My suggestion would be to have something like this:
>
>if (env_get_yesno("fsl_bootcmd_set") <= 0) {
> // Set the default bootcmd according to the boot device
> ...
> env_set("fsl_bootcmd_set", "y");
>}
>
> That way it doesn't matter what the default value of `bootcmd` is and boards
> also have the possibility to disable this code by setting `fsl_bootcmd_set`
> to `y`
> in their default env.
>
> I think it would also make sense to have some code that set the TF-A boot
> device in the env, that might allow handling this in the boot scripts directly
> instead of all this hard coded logic.
>
> Alban
Thank you for explaining it. I could reproduce the issue in case we enable
SYS_REDUNDAND_ENVIRONMENT.
Fixed it using another env variable as you suggested. Below are my test steps
on lx2160ardb with xspi and SD boot.
XSPI BOOT ###
=> qixis_reset altbank
Loading Environment from SPIFlash... SF: Detected mt35xu512aba with page size
256 Bytes, erase size 128 KiB, total 64 MiB
*** Warning - bad CRC, using default environment
=> pri bootcmd
bootcmd=sf probe 0:0; sf read 0x806c 0x6c 0x4; env exists mcinitcmd
&& env exists secureboot && esbc_validate 0x806c; sf read 0x80d0
0xd0 0x10; env exists mcinitcmd && fsl_mc lazyapply dpl 0x80d0; run
distro_bootcmd;run xspi_bootcmd; env exists secureboot && esbc_halt;
=> pri mcinitcmd
mcinitcmd=sf probe 0:0 && sf read 0x8064 0x64 0x8 && env exists
secureboot && esbc_validate 0x8064 && esbc_validate 0x8068; sf read
0x80a0 0xa0 0x30 && sf read 0x80e0 0xe0 0x10; fsl_mc
start mc 0x80a0 0x80e0
=> pri fsl_bootcmd_mcinitcmd_set
fsl_bootcmd_mcinitcmd_set=y
=> setenv bootcmd run xspi_bootcmd
=> saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI
flash...done
Valid environment: 2
OK
=> pri bootcmd
bootcmd=run xspi_bootcmd
=> qixis_reset altbank
=> pri bootcmd
bootcmd=run xspi_bootcmd
=> env default -a;saveenv
## Resetting to default environment
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI
flash...done
Valid environment: 1
OK
=> qixis_reset altbank
=> pri bootcmd
bootcmd=sf probe 0:0; sf read 0x806c 0x6c 0x4; env e
Re: [RFC PATCH 02/28] cli: Add LIL shell
Hi On Wed, Jul 7, 2021 at 4:48 PM Marek Behun wrote: > > Dear Tom, Sean, Wolfgang and others, > > here are some of my opinions for this discussion > > - I agree with Wolfgang that there are far better options than > a Tcl-like shell, if we want to add another language > > - I also think that instead of adding another language, it is more > preferable to improve the existing one. Adding a new language will > cause more problems in the future: > - I think it can end up with OS distributions needing to write > boot scripts in both languages, because they can't be sure which > will be compiled into U-Boot > - we will certainly end up with more bugs > - userbase will fragment between the two languages > > - I think we can start improving the current U-Boot's shell in ways > that are incompatible with upstream Hush. > > The idea back then, as I understand it, was to minimize man-hours > invested into the CLI code, and so an existing shell was incorporated > (with many #ifdef guards). But U-Boot has since evolved so much that > it is very probable it would be more economic to simply fork from > upsteam Hush, remove all the #ifdefs and start developing features we > want in U-Boot. Is upstream Hush even maintained properly? > What is the upstream repository? Is it > https://github.com/sheumann/hush? > I think that hush is the one that is now in the busybox. I could spent ten minutes this morning and this is my short list: - we have several define that allow it to enabled e/o disable a lot of features - we are talking about 11K lines compared to 3K (including comment) - we have 25-30 configuration option on hush on busybox - in u-boot code some of the problem was solved some time ago - as describe is 68Kb, I think this consider all the option enables - the code is different from what we have and what is there I don't know if options like ENABLE_HUSH_JOB and ENABLE_MMU can partially solve some of the problems described in the thread * Sean *: You have spent more on this, can you please complete it. Out of that. Do we have some script shell unit test in uboot? Michael > - even if we decide to stay with upstream Hush and just upgrade > U-Boot's Hush to upstream (since it supports functions, arithmetic > with $((...)), command substitution with $(...), these are all nice > features), it is IMO still better than adding a new language > > - one of the points Sean mentioned with LIL is that when compiled, it's > size does not exceed the size of U-Boot's Hush. > > If we were to add new features into U-Boot's Hush, the code size would > certainly increase. > > I think we should implement these new features, and instead of adding > a new language, we should work on minimizing the code size / > resulting U-Boot image size. This is where U-Boot will gain most not > only with it's CLI, but also everywhere else. Regarding this, > - we already have LTO > - Simon worked on dtoc so that devicetrees can be compiled into C code > - we can start playing with compression > - either we can compress the whole image for machines with enough > RAM but small place for U-Boot (Nokia N900 for example has only > 256 KiB space for U-Boot) > - or we can try to invent a way to decompress code when it is > needed, for machines with small RAM > > Marek -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [RFC PATCH 02/28] cli: Add LIL shell
On 7/6/21 3:44 AM, Wolfgang Denk wrote: Dear Tom, In message <20210705191058.GB9516@bill-the-cat> you wrote: This is I think the hard question. A draw of the current shell is that it it looks and acts like bash/sh/etc, for at least basic operations. That's something that's comfortable to a large audience. That has disadvantages when people want to start doing something complex. Sean has shown that several times and he's not the only one. LIL being tcl'ish is not. Tcl is a horror of a language for anything that is above trivial level. Can you please elaborate on this? You've made this claim several times, but haven't explained your reasoning for it. --Sean
Re: [RFC PATCH 05/28] cli: lil: Rename some functions to be more like TCL
On 7/6/21 3:50 AM, Wolfgang Denk wrote: Dear Sean, In message <7143cb1e-4061-3034-57b9-1a12753fa...@gmail.com> you wrote: You complain that the existing port of hus has a number of severe limitations or bugs which have long been fixed upstream, The bugs are fairly minor. The particular characteristics of Hush have not changed. These characteristics make Hush difficult to adapt to the limitations of U-Boot. When we cannot support the basic abstractions expected by Hush, the shell will necessarily change for the worse. This is not true. Just have a look what hush in a recent version of Busybox offers. Busybox runs in a Linux environment. Many of its features rely on the core functionality provided by Linux, which we do not provide in U-Boot. This is what makes porting features difficult. but cannot be easily fixed in U-Boot Because they are core to the design of Hush (and other bourne derived shells). Oh, this is an interesting opinion. I doubt if a majority (or even a significant percentage) of U-Boot users share it. If you were right, there would be far less users of bash (or other "bourne derived shells"). Guess which percentage of users of UNIX operating systems is using a Tcl based command interpreter as their login shell? And yet, this is not the field we compete in. While bourne-style shells can take advantage of a multi-threaded environment, embedded shells tend to implement a much wider set of languages. See [1] for a survey of examples. --Sean [1] https://github.com/dbohdan/embedded-scripting-languages
Re: [PATCH] doc: fix typo in signature.txt
On 7/2/21 11:32 AM, Thomas Perrot wrote:
Fix value fields in signature nodes.
Signed-off-by: Thomas Perrot
This matches the definition
include/image.h:1004:
#define FIT_VALUE_PROP "value"
Reviewed-by: Heinrich Schuchardt
---
doc/uImage.FIT/signature.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index d9a912119032..7cb1c15e5e15 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -266,14 +266,14 @@ As an example, consider this FIT:
data = ;
signature-1 {
algo = "sha1,rsa2048";
- vaue = <...fdt signature 1...>
+ value = <...fdt signature 1...>
};
};
fdt-2 {
data = ;
signature-1 {
algo = "sha1,rsa2048";
- vaue = <...fdt signature 2...>
+ value = <...fdt signature 2...>
};
};
};
Re: [RFC PATCH 03/28] cli: lil: Replace strclone with strdup
On 7/5/21 1:50 PM, Wolfgang Denk wrote: Dear Sean, In message <5a967151-94f0-6037-2d02-0114c43b8...@gmail.com> you wrote: AIUI hush has diverged significantly from what U-Boot has. This would not be an "update" moreso than a complete port in the style of the current series. Agreed. However, as you write this it sounds like a big problem only. I disagree here - it is also a chance to do a few things different than with the original port. Please keep in mind when this original port of the hush shell was done: it was a time when many systems came with a total of 4 MB flash memory, and not only U-Boot, but also the Linux kernel and a ram-disk image or such had to fit into that. At that time 40 or 60 kB code size for just a fancy shell was immense! Under such restrictions (and the need to complete the task with a given budget) many things were just commented out which from today's point of view would be nice to have. This is not a problem of the code complexity or resources, but only of different requirements and different resources. I don't think sh-style shells are a good match for U-Boot's execution environment in the first place. The fundamental idea of an sh-style shell is that the output of one command can be redirected to the input (or arguments) of another command. This cannot be done (or rather would be difficult to do) in U-Boot for a few reasons There is an old saying: The loser says: "It might be possible, but it is too difficult." The winner says: "It might be difficult, but it is possible." And yet, the winner may also say "this is too difficult to be worth it" instead of laboring inefficiently :) Apparently you take another position here than me. First, I disagree that pipes are the "fundamental idea" of a shell. It is a fundamental idea of the UNIX operating systems, indeed. Well, I think all programming languages at their core are about transferring information from one part of the program to another. Without pipes, how do bourne-style shells communicate? Sure you can transfer data into functions using arguments, but what about the other way around? Numeric return values? Global variables? I think these are rather anemic compared to proper return values. But please keep in mind that we are here in a boot loader, not in a full-blown OS context. * U-Boot does not support multithreading. Existing shells tend to depend strongly on this feature of the enviromnent. Many of the changes to U-Boot's hush are solely to deal with the lack of this feature. I disagree to both parts of your statement. Multithreading (or rather, a concept of separate processes which can eventually even run in parallel) is very nice to have, but it is not mandatory in most cases. Command pipes can almost always be strictly sequentialized and thus run in a single-task environment, too. I'm not sure, but I think I even remember pipes in the "shell" of the CPM "OS" on Z80 processors a number of decades ago... The point here is that many Hush features were written with fork. For example, to create a new scope (such as for a subshell), Hush just fork()s. When parsing, if it encounters a construct like $(), it fork()s and then modifies the map variable, (correctly) assuming that the "original" map will remain unmodified. These things are all over and make doing a port difficult; especially when they crop up as unforseen bugs. Though I suppose the real issue here is a lack of virtual memory. And the fact that our current version of hush did not attempt to keep these features was much more driven by strict memory footprint limitations that anything else. I claim it would have been possible, and still is. You also don't mention (and I guess you oversee) another critical fact: so far, U-Boot has no concept of files. The classic design principle "everything is a file" is missing even more than the concept of processes. IMO "everything is a file" is more of an API thing than a shell thing. E.g. the idea that you can use open/read/write/close to access any resource. But without pipes, I don't think such an abstraction is very useful. * Existing commands do not read from stdin, nor do they print useful information to stdout. Command output is designed for human consumption and is substantially more verbose than typical unix commands. This is a statement which is correct, but it does not contain any pro or con for the discussion here. In order for pipes to be useful, programs should generally follow the Unix philosophy. In particular, many commands in U-Boot fall afoul of rule 2: Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Which makes it difficult to compose them. And if we had the features, it would be easy to fix. I don't know about that. I think making U-Boot co
Re: [RFC PATCH 00/28] cli: Add a new shell
On 7/7/21 11:49 PM, Heiko Schocher wrote:
Hello Sean,
On 01.07.21 08:15, Sean Anderson wrote:
Well, this has been sitting on my hard drive for too long without feedback
("Release early, release often"), so here's the first RFC. This is not ready to
merge (see the "Future work" section below), but the shell is functional and at
least partially tested.
The goal is to have 0 bytes gained over Hush. Currently we are around 800 bytes
over on sandbox.
add/remove: 90/54 grow/shrink: 3/7 up/down: 12834/-12042 (792)
Thanks for this comparison. Here just my thoughts, but I have currently to
low time to follow here completly, so sorry if I miss stuff already
discussed.
From my side of view we can add a second shell beside hush, and as you
already mentioned it may is even possible to start LIL from hush. This
would be cool.
But I disagree in the following points:
- I do not see why LIL should *replace* hush.
This is the eventual goal. This series just adds an option at build time
(CONFIG_LIL) which uses LIL as the shell instead of Hush. But anyone who
writes a series like this must be convinced that it is better than what
already exists. So I write that my goal is to replace hush, even if I
think that it will take a long while.
This may break a lot of current boards. Also I see no need to do
this, as if you do complex stuff in u-boot shell it may is the
wrong way and you have to think about... and I see no big
discussions here about BUGS in our current hush implementation ...
may it makes sense to bring them up and fix?
I have been told not to work on the current shell; that it is too old
and there is no point in improving it. Since we will be starting afresh
anyway, and I do not think that the Hush model is particularly good, I
chose to work from a different base.
- Is LIL really so good code, that it is done? Or is there only no community
which develop further?
AFAIK there is not too much of a LIL community. The code quality is
something I found out after working on it for a while. From a cursory
inspection, it was around the same as all the other shells I looked at
(no comments, etc). FWIW the current Hush shell does not really handle
errors either. For example, on (x)malloc failure, we print and hang.
This could easily be done for LIL, but it is not so nice when your
language has recursion. So I have tried to add error checking where
possible. And of course, Hush ignores missing variables as well.
- Do we really want code, which does no error checking? Commentless code...
you wrote:
- There is a serious error handling problem. Most original LIL code never
checked errors. In almost every case, errors were silently ignored, even
malloc failures! While I have designed new code to handle errors properly,
Which really let me think, nobody is interested in this code ... this
sounds like crap... and this brings me to the next point
- Do we not have the same problem as with hush, if we change LIL code?
I think the primary problem with Hush was that we expected to backport
updates at all. I think such a core UI feature should not have so many
ifdefs in it when no backport was ever made. It is difficult to modify
Hush because not only do you have to understand how U-Boot uses some
feature, you also have to understand how Busybox uses some feature. And
Hush of course has less comments as LIL does (after all patches in this
series are applied).
Do you plan to upstream your changes?
I don't view it as especially important. I view LIL as a starting point
which can be modified to suit U-Boot. It may end up that each individual
component is changed in some way, but starting with a working shell has
been very helpful for development.
So please do not understand me wrong, I see you invested much time here,
but I see LIL not in the short term as a replacement for hush.
I would accept to add LIL as an option and we will see, how good it works.
That is what I intend to do.
And if we have in lets say 2-3 years more boards which use LIL instead of
hush *and* also active maintained LIL code, we may can think of getting rid
of hush... and may have a "hush compatibility" layer...
I have no idea of current hush mainline code and how many work it will be
to update U-Boot to a current hush version. But may this would be make more
sense as hush is in active development. Also may to discuss with hush
maintainers
to upstream U-Boot changes... this would make in my eyes more sense.
AFAICT most of the U-Boot changes are removal of features, workarounds
for unimplemented functionality (e.g. anywhere Hush does fork/exec), and
some small additions like command repetition which cannot be upstreamed
because it would break any semblance of POSIX compatibility.
--Sean
= Why Lil?
When looking for a suitable replacement shell, I evaluated implementations using
the following criteria:
- It must have a GPLv2-compatible license.
- It must be written in C, and have no major
Re: [PATCH v4 4/8] common: Rename macro appropriately
Hello Steffen, On 08.07.21 01:09, Steffen Jaeckel wrote: > While doing code-review internally this got nitpicked by 2 reviewers, so > I decided to include this here. > > Signed-off-by: Steffen Jaeckel > Reviewed-by: Simon Glass > --- > > (no changes since v1) > > common/autoboot.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v4 3/8] common: integrate crypt-based passwords
Hello Steffen, On 08.07.21 01:09, Steffen Jaeckel wrote: > Hook into the autoboot flow as an alternative to the existing > mechanisms. > > Signed-off-by: Steffen Jaeckel > Reviewed-by: Simon Glass > --- > > (no changes since v1) > > common/Kconfig.boot | 38 ++--- > common/autoboot.c | 81 - > 2 files changed, 105 insertions(+), 14 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v4 2/8] lib: wrap crypt API to hide errno usage
Hello Steffen, On 08.07.21 01:09, Steffen Jaeckel wrote: > In order to prevent using the global errno, replace it with a static > version and create a wrapper function which returns the error value. > > Signed-off-by: Steffen Jaeckel > Reviewed-by: Simon Glass > --- > > (no changes since v1) > > include/crypt.h | 3 ++- > lib/crypt/alg-sha256.h | 6 -- > lib/crypt/alg-sha512.h | 6 -- > lib/crypt/crypt-port.h | 18 ++ > lib/crypt/crypt-sha256.c | 26 -- > lib/crypt/crypt-sha512.c | 26 -- > lib/crypt/crypt.c| 25 ++--- > test/lib/test_crypt.c| 24 ++-- > 8 files changed, 96 insertions(+), 38 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v4 1/8] lib: add crypt subsystem
Hello Steffen, On 08.07.21 01:09, Steffen Jaeckel wrote: > Add the basic functionality required to support the standard crypt > format. > The files crypt-sha256.c and crypt-sha512.c originate from libxcrypt and > their formatting is therefor retained. > The integration is done via a crypt_compare() function in crypt.c. > > ``` > libxcrypt $ git describe --long --always --all > tags/v4.4.17-0-g6b110bc > ``` > > Signed-off-by: Steffen Jaeckel > Reviewed-by: Simon Glass > --- > > Changes in v4: > Fix depends for unit-tests > > Changes in v3: > Add unit-tests for autoboot > Introduce `bootstopusesha256` to allow fallback to plain SHA256-based > hashing > Add AUTOBOOT_FLUSH_STDIN option > Drop the changes to bcm963158_ram_defconfig > > Changes in v2: > Update Kconfig way of enabling, setting hashes etc. > > Changes in v1: > Added unit-tests of crypt_compare() > Wrapped crypt functions to encapsulate errno Reviewed-by: Heiko Schocher Nitpicks below... > include/crypt.h | 13 ++ > lib/Kconfig | 1 + > lib/Makefile | 1 + > lib/crypt/Kconfig| 28 > lib/crypt/Makefile | 10 ++ > lib/crypt/alg-sha256.h | 17 ++ > lib/crypt/alg-sha512.h | 17 ++ > lib/crypt/crypt-port.h | 28 > lib/crypt/crypt-sha256.c | 313 + > lib/crypt/crypt-sha512.c | 328 +++ > lib/crypt/crypt.c| 73 + > test/Kconfig | 10 ++ > test/lib/Makefile| 1 + > test/lib/test_crypt.c| 44 ++ > 14 files changed, 884 insertions(+) > create mode 100644 include/crypt.h > create mode 100644 lib/crypt/Kconfig > create mode 100644 lib/crypt/Makefile > create mode 100644 lib/crypt/alg-sha256.h > create mode 100644 lib/crypt/alg-sha512.h > create mode 100644 lib/crypt/crypt-port.h > create mode 100644 lib/crypt/crypt-sha256.c > create mode 100644 lib/crypt/crypt-sha512.c > create mode 100644 lib/crypt/crypt.c > create mode 100644 test/lib/test_crypt.c [...] > diff --git a/lib/crypt/Makefile b/lib/crypt/Makefile > new file mode 100644 > index 00..290231064c > --- /dev/null > +++ b/lib/crypt/Makefile > @@ -0,0 +1,10 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# > +# Copyright (c) 2013, Google Inc. > +# > +# (C) Copyright 2000-2007 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. Hmm... this is a new file ... I think you should add only your Copyright and drop the others... ? > +obj-$(CONFIG_CRYPT_PW) += crypt.o > +obj-$(CONFIG_CRYPT_PW_SHA256) += crypt-sha256.o > +obj-$(CONFIG_CRYPT_PW_SHA512) += crypt-sha512.o [...] > diff --git a/lib/crypt/crypt-sha256.c b/lib/crypt/crypt-sha256.c > new file mode 100644 > index 00..37127d41e1 > --- /dev/null > +++ b/lib/crypt/crypt-sha256.c > @@ -0,0 +1,313 @@ > +/* One way encryption based on the SHA256-based Unix crypt implementation. > + * > + * Written by Ulrich Drepper in 2007 [1]. > + * Modified by Zack Weinberg in 2017, 2018. > + * Composed by Björn Esser in 2018. > + * Modified by Björn Esser in 2020. > + * Modified by Steffen Jaeckel in 2020. > + * To the extent possible under law, the named authors have waived all > + * copyright and related or neighboring rights to this work. > + * > + * See https://creativecommons.org/publicdomain/zero/1.0/ for further > + * details. > + * > + * This file is a modified except from [2], lines 648 up to 909. > + * > + * [1] https://www.akkadia.org/drepper/sha-crypt.html > + * [2] https://www.akkadia.org/drepper/SHA-crypt.txt > + */ I miss here the SPDX license identifier... also some hint, from which exact version this code is from ... > diff --git a/lib/crypt/crypt-sha512.c b/lib/crypt/crypt-sha512.c > new file mode 100644 > index 00..3616019445 > --- /dev/null > +++ b/lib/crypt/crypt-sha512.c > @@ -0,0 +1,328 @@ > +/* One way encryption based on the SHA512-based Unix crypt implementation. > + * > + * Written by Ulrich Drepper in 2007 [1]. > + * Modified by Zack Weinberg in 2017, 2018. > + * Composed by Björn Esser in 2018. > + * Modified by Björn Esser in 2020. > + * Modified by Steffen Jaeckel in 2020. > + * To the extent possible under law, the named authors have waived all > + * copyright and related or neighboring rights to this work. > + * > + * See https://creativecommons.org/publicdomain/zero/1.0/ for further > + * details. > + * > + * This file is a modified except from [2], lines 1403 up to 1676. > + * > + * [1] https://www.akkadia.org/drepper/sha-crypt.html > + * [2] https://www.akkadia.org/drepper/SHA-crypt.txt > + */ same here Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [RFC PATCH 00/28] cli: Add a new shell
Hello Sean,
On 01.07.21 08:15, Sean Anderson wrote:
> Well, this has been sitting on my hard drive for too long without feedback
> ("Release early, release often"), so here's the first RFC. This is not ready
> to
> merge (see the "Future work" section below), but the shell is functional and
> at
> least partially tested.
>
> The goal is to have 0 bytes gained over Hush. Currently we are around 800
> bytes
> over on sandbox.
>
> add/remove: 90/54 grow/shrink: 3/7 up/down: 12834/-12042 (792)
Thanks for this comparison. Here just my thoughts, but I have currently to
low time to follow here completly, so sorry if I miss stuff already
discussed.
>From my side of view we can add a second shell beside hush, and as you
already mentioned it may is even possible to start LIL from hush. This
would be cool.
But I disagree in the following points:
- I do not see why LIL should *replace* hush. This may break a lot of
current boards. Also I see no need to do this, as if you do complex
stuff in u-boot shell it may is the wrong way and you have to think
about... and I see no big discussions here about BUGS in our current
hush implementation ... may it makes sense to bring them up and fix?
- Is LIL really so good code, that it is done? Or is there only no community
which develop further?
- Do we really want code, which does no error checking? Commentless code...
you wrote:
> - There is a serious error handling problem. Most original LIL code never
> checked errors. In almost every case, errors were silently ignored, even
> malloc failures! While I have designed new code to handle errors properly,
Which really let me think, nobody is interested in this code ... this
sounds like crap... and this brings me to the next point
- Do we not have the same problem as with hush, if we change LIL code?
Do you plan to upstream your changes?
So please do not understand me wrong, I see you invested much time here,
but I see LIL not in the short term as a replacement for hush.
I would accept to add LIL as an option and we will see, how good it works.
And if we have in lets say 2-3 years more boards which use LIL instead of
hush *and* also active maintained LIL code, we may can think of getting rid
of hush... and may have a "hush compatibility" layer...
I have no idea of current hush mainline code and how many work it will be
to update U-Boot to a current hush version. But may this would be make more
sense as hush is in active development. Also may to discuss with hush
maintainers
to upstream U-Boot changes... this would make in my eyes more sense.
> = Why Lil?
>
> When looking for a suitable replacement shell, I evaluated implementations
> using
> the following criteria:
>
> - It must have a GPLv2-compatible license.
> - It must be written in C, and have no major external dependencies.
> - It must support bare function calls. That is, a script such as 'foo bar'
> should invoke the function 'foo' with the argument 'bar'. This preserves the
> shell-like syntax we expect.
> - It must be small. The eventual target is that it compiles to around 10KiB
> with
> -Os and -ffunction-sections.
> - There should be good tests. Any tests at all are good, but a functioning
> suite
> is better.
> - There should be good documentation
> - There should be comments in the source.
> - It should be "finished" or have only slow development. This will hopefully
> make it easier to port changes.
>
> Notably absent from the above list is performance. Most scripts in U-Boot will
> be run once on boot. As long as the time spent evaluating scripts is kept
> under
> a reasonable threshold (a fraction of the time spend initializing hardware or
> reading data from persistant storage), there is no need to optimize for speed.
>
> In addition, I did not consider updating Hush from Busybox. The mismatch in
> computing environment expectations (as noted in the "New shell" section above)
> still applies. IMO, this mismatch is the biggest reason that things like
> functions and command substitution have been excluded from the U-Boot's Hush.
>
> == lil
>
> - zLib
> - TCL
> - Compiles to around 10k with no builtins. To 25k with builtins.
> - Some tests, but not organized into a suite with expected output. Some
> evidence
> that the author ran APL, but no harness.
> - Some architectural documentation. Some for each functions, but not much.
> - No comments :l
> - 3.5k LoC
>
> == picol
>
> - 2-clause BSD
> - TCL
> - Compiles to around 25k with no builtins. To 80k with builtins.
> - Tests with suite (in-language). No evidence of fuzzing.
> - No documentation :l
> - No comments :l
> - 5k LoC
>
> == jimtcl
>
> - 2-clause BSD
> - TCL
> - Compiles to around 95k with no builtins. To 140k with builtins. Too big...
>
> == boron
>
> - LGPLv3+ (so this is right out)
> - REBOL
> - Compiles to around 125k with no builtins. To 190k with builtins. Too big...
>
> == libmawk
>
> - GPLv2
> - Awk
> - Compiles to around 225k.
Re: [PATCH 11/18] arm: Remove nsa310s board
Thanks Tom! I think we are almost done with the DM conversion for NSA310S. I'm waiting for Setfan's feedback on one last patch revision. -Tony On Wed, Jul 7, 2021 at 7:55 PM Tom Rini wrote: > On Wed, Jul 07, 2021 at 10:54:21PM -0400, Tom Rini wrote: > > > On Sat, May 22, 2021 at 08:47:10AM -0400, Tom Rini wrote: > > > > > These boards have not been converted to CONFIG_DM_USB by the deadline > > > and is also missing conversion to CONFIG_DM. Remove it > > > > > > Cc: Gerald Kerma > > > Cc: Tony Dinh > > > Cc: Luka Perkov > > > Signed-off-by: Tom Rini > > > > Applied to u-boot/master, thanks! > > Apologies, I only realized there had been a recent series to address > this as I was hitting send. I have reverted the removal, sorry! > > -- > Tom >
Re: [PATCH 11/18] arm: Remove nsa310s board
On Wed, Jul 07, 2021 at 10:54:21PM -0400, Tom Rini wrote: > On Sat, May 22, 2021 at 08:47:10AM -0400, Tom Rini wrote: > > > These boards have not been converted to CONFIG_DM_USB by the deadline > > and is also missing conversion to CONFIG_DM. Remove it > > > > Cc: Gerald Kerma > > Cc: Tony Dinh > > Cc: Luka Perkov > > Signed-off-by: Tom Rini > > Applied to u-boot/master, thanks! Apologies, I only realized there had been a recent series to address this as I was hitting send. I have reverted the removal, sorry! -- Tom signature.asc Description: PGP signature
Re: [PATCH 17/18] usb: Add correct depends for CMD_USB_MASS_STORAGE
On Sat, May 22, 2021 at 08:47:16AM -0400, Tom Rini wrote: > We cannot build this without USB_GADGET_DOWNLOAD support enabled, add > the appropriate depends line. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 16/18] sniper: Add build guards around MUSB support code
On Sat, May 22, 2021 at 08:47:15AM -0400, Tom Rini wrote: > If MUSB support is disabled, these parts of the code will fail to build. > > Cc: Paul Kocialkowski > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 15/18] arm: Remove spear600 boards and the rest of SPEAr support
On Sat, May 22, 2021 at 08:47:14AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove them. As this is > the last of the SPEAr platforms, so remove the rest of the remaining > support as well. > > Cc: Vipin Kumar > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/18] arm: Remove spear320 boards
On Sat, May 22, 2021 at 08:47:13AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove them. As this is > also the last SPEAR3XX platform, remove that symbol as well. > > Cc: Vipin Kumar > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 13/18] arm: Remove spear310 boards
On Sat, May 22, 2021 at 08:47:12AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove them. > > Cc: Vipin Kumar > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/18] arm: Remove spear300 boards
On Sat, May 22, 2021 at 08:47:11AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove them. > > Cc: Vipin Kumar > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/18] arm: Remove nsa310s board
On Sat, May 22, 2021 at 08:47:10AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove it > > Cc: Gerald Kerma > Cc: Tony Dinh > Cc: Luka Perkov > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 10/18] arm: Remove gplugd board
On Sat, May 22, 2021 at 08:47:09AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove it > > Cc: Ajay Bhargav > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/18] arm: Remove edb9315a board
On Sat, May 22, 2021 at 08:47:08AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove it. > > This is also the last PL010_SERIAL using board, so remove those > references. > > Cc: Sergey Kostanbaev > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 08/18] arm: Remove at91rm9200ek boards
On Sat, May 22, 2021 at 08:47:07AM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_USB by the deadline > and is also missing conversion to CONFIG_DM. Remove them. > > Cc: Andreas Bießmann > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL
On Sat, May 22, 2021 at 08:47:06AM -0400, Tom Rini wrote: > As this board does not use CONFIG_OF_CONTROL and the DM_USB migration > deadline has passed, disable USB_GADGET support. > > Cc: Eric Nelson > Cc: Stefano Babic > Signed-off-by: Tom Rini > Acked-by: Eric Nelson Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 06/18] dockstar: Perform base CONFIG_DM enablement
On Sat, May 22, 2021 at 08:47:05AM -0400, Tom Rini wrote: > As these boards support CONFIG_OF_CONTROL today, perform a basic > CONFIG_DM migration. > > Cc: Eric Cooper > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/18] ib62x0: Perform base CONFIG_DM enablement
On Sat, May 22, 2021 at 08:47:04AM -0400, Tom Rini wrote: > As these boards support CONFIG_OF_CONTROL today, perform a basic > CONFIG_DM migration. > > Cc: Luka Perkov > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/18] iconnect: Perform base CONFIG_DM enablement
On Sat, May 22, 2021 at 08:47:03AM -0400, Tom Rini wrote: > As these boards support CONFIG_OF_CONTROL today, perform a basic > CONFIG_DM migration. > > Cc: Luka Perkov > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/18] pogo_e02: Perform base CONFIG_DM enablement
On Sat, May 22, 2021 at 08:47:02AM -0400, Tom Rini wrote: > As these boards support CONFIG_OF_CONTROL today, perform a basic > CONFIG_DM migration. > > Cc: Dave Purdy > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/18] openrd: Perform base CONFIG_DM enablement
On Sat, May 22, 2021 at 08:47:01AM -0400, Tom Rini wrote: > As these boards support CONFIG_OF_CONTROL today, perform a basic > CONFIG_DM migration. > > Cc: Stefan Roese > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/18] snapper9260/snapper9g20: Disable USB
On Sat, May 22, 2021 at 08:47:00AM -0400, Tom Rini wrote: > These boards have not converted to DM_USB by the deadline, disable USB > support as they do not enable CONFIG_OF_CONTROL. > > Cc: Simon Glass > u-boot@lists.denx.de (open list) Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCHv2 25/27] ppc: Remove T4160RDB board
On Sun, May 23, 2021 at 10:58:05AM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. As this is the last > ARCH_T4160 platform, remove that support as well. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 26/27] configs: Remove unnecessary CONFIG_DM_PCI_COMPAT=y
On Fri, May 14, 2021 at 09:34:31PM -0400, Tom Rini wrote: > The following boards no longer need CONFIG_DM_PCI_COMPAT enabled, so > remove that. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 24/27] ppc: Remove MPC832XEMDS boards
On Fri, May 14, 2021 at 09:34:29PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove them. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 23/27] ppc: Remove MPC8323ERDB board
On Fri, May 14, 2021 at 09:34:28PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 22/27] ppc: Remove MPC8315ERDB board
On Fri, May 14, 2021 at 09:34:27PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. As this is the last > ARCH_MPC8315 platform, remove that support as well. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 21/27] ppc: Remove sbc8641d board
On Fri, May 14, 2021 at 09:34:26PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. This is also the last > of the ARCH_MPC8641/MPC8610 platforms, so remove that support as well. > > Cc: Paul Gortmaker > Cc: Priyanka Jain > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 20/27] ppc: Remove xpedite boards
On Fri, May 14, 2021 at 09:34:25PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove them. As this includes > the last ARCH_MPC8572 platform, remove that as well. > > Cc: Peter Tyser > Signed-off-by: Tom Rini > Acked-by: Peter Tyser Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 19/27] ppc: Remove kmcoge4 board
On Fri, May 14, 2021 at 09:34:24PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. > > Cc: Valentin Longchamp > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 18/27] ppc: Remove MPC8568MDS board
On Fri, May 14, 2021 at 09:34:23PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. As this is the last > ARCH_MPC8568 platform, remove that support as well. > > Cc: Priyanka Jain > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 17/27] ppc: Remove T1023RBD boards and T1024RDB_SECURE_BOOT
On Fri, May 14, 2021 at 09:34:22PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline > and is also missing conversion to CONFIG_DM. Remove them. As this is > the only ARCH_T1023 platform left, remove that support as well. > > Cc: Priyanka Jain > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 16/27] ppc: Remove MPC8555CDS boards
On Fri, May 14, 2021 at 09:34:21PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove them. As this is the only > ARCH_MPC8555 platform left, remove that support as well. > > Cc: Priyanka Jain > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 15/27] ppc: Remove MPC8541CDS board
On Fri, May 14, 2021 at 09:34:20PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. As this is the only > MPC8541 target left, remove that architecture support as well. > > Cc: Priyanka Jain > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/27] ppc: Remove TQM834x board
On Fri, May 14, 2021 at 09:34:19PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline and is > also missing conversion to CONFIG_DM. Remove it. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 13/27] ppc: Remove sbc8548 boards
On Fri, May 14, 2021 at 09:34:18PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline and are > also missing conversion to CONFIG_DM. Remove them. > > Cc: Paul Gortmaker > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/27] ppc: Remove caddy2 / vme8349 boards
On Fri, May 14, 2021 at 09:34:17PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline > and is also missing conversion to CONFIG_DM. Remove them. > > Cc: Reinhard Arlt > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/27] ppc: Remove MPC8313ERDB boards
On Fri, May 14, 2021 at 09:34:16PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI by the deadline. > Remove them. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 10/27] ppc: Remove ve8313 board
On Fri, May 14, 2021 at 09:34:15PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline. > Remove it. > > Cc: Heiko Schocher > Signed-off-by: Tom Rini > Acked-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/27] ppc: Remove mpc8308_p1m board
On Fri, May 14, 2021 at 09:34:14PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_PCI by the deadline. > Remove it. > > Cc: Ilya Yanok > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 08/27] ppc: Remove many T104x boards
On Fri, May 14, 2021 at 09:34:13PM -0400, Tom Rini wrote: > These boards have not been converted to CONFIG_DM_PCI, CONFIG_DM_USB or > in some cases CONFIG_DM itself by the deadline. Remove them. > > Cc: Priyanka Jain > Cc: Ruchika Gupta > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/27] ppc: Remove sbc8349 board
On Fri, May 14, 2021 at 09:34:12PM -0400, Tom Rini wrote: > This board has not been converted to CONFIG_DM_MMC by the deadline. > Remove it. > > Cc: Paul Gortmaker > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/27] m68k: Remove M5475x boards
On Fri, May 14, 2021 at 09:34:10PM -0400, Tom Rini wrote: > These board has not been converted to CONFIG_DM_PCI by the deadline. > Remove them. As this is the last of the mcf547x_8x family of boards, > remove that support as well. > > Cc: TsiChung Liew > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/27] m68k: Remove M5485 boards
On Fri, May 14, 2021 at 09:34:09PM -0400, Tom Rini wrote: > These board has not been converted to CONFIG_DM_PCI by the deadline. > Remove them. As this is all of the CONFIG_M548x platforms as well, > remove that code. > > Cc: TsiChung Liew > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/27] ppc: Drop MPC837XERDB_SLAVE for now
On Fri, May 14, 2021 at 09:34:07PM -0400, Tom Rini wrote: > Drop the MPC837XERDB_SLAVE configuration. > > Cc: Sinan Akman > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/27] pci: Remove non-DM board_pci_fixup_dev() declaration
On Fri, May 14, 2021 at 09:34:06PM -0400, Tom Rini wrote: > With the ventana boards migrated to DM_PCI and DM_ETH, we can remove > this prototype. > > Cc: Stefano Babic > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] efi_loader: add boot variable measurement
On Thu, 8 Jul 2021 at 03:56, Ilias Apalodimas
wrote:
>
> Hi Kojima-san,
> > +{
>
> [...]
>
> > + u16 *boot_order;
> > + u16 var_name[] = L"BootOrder";
> > + u16 boot_name[] = L"Boot";
> > + u16 hexmap[] = L"0123456789ABCDEF";
> > + u8 *bootvar;
> > + efi_uintn_t var_data_size;
> > + u32 count, i;
> > + efi_status_t ret;
> > +
> > + boot_order = efi_get_var(var_name, &efi_global_variable_guid,
> > + &var_data_size);
> > + if (!boot_order) {
> > + log_info("BootOrder not defined\n");
> > + ret = EFI_NOT_FOUND;
> > + goto error;
> > + }
> > +
> > + ret = tcg2_measure_variable(dev, 1, EV_EFI_VARIABLE_BOOT2, var_name,
> > + &efi_global_variable_guid, var_data_size,
> > + (u8 *)boot_order);
> > + if (ret != EFI_SUCCESS)
> > + goto error;
> > +
> > + count = var_data_size / sizeof(*boot_order);
> > + for (i = 0; i < count; i++) {
> > + boot_name[4] = hexmap[(boot_order[i] & 0xf000) >> 12];
> > + boot_name[5] = hexmap[(boot_order[i] & 0x0f00) >> 8];
> > + boot_name[6] = hexmap[(boot_order[i] & 0x00f0) >> 4];
> > + boot_name[7] = hexmap[(boot_order[i] & 0x000f)];
>
> Can you use efi_create_indexed_name() instead?
I have not noticed this utility function, thank you.
>
> [...]
> > + for (pcr_index = 0; pcr_index <= 7; pcr_index++) {
> > + ret = tcg2_measure_event(dev, pcr_index, EV_SEPARATOR,
> > + sizeof(event), (u8 *)&event);
>
> I assume adding a separator event on all these PCRs is described on the
> standard?
Yes, TCG spec requires EV_SEPARATOR event prior to the first invocation of
the first Ready to Boot call.
Spec also says EV_SEPARATOR must be the last entry for PCR0, 1, 2, 3, 6.
>
> > + if (ret != EFI_SUCCESS)
> > + goto out;
> > + }
> > +
> > + tcg2_efi_app_invoked = true;
> > +out:
> > + return ret;
> > +}
> > +
> > +/**
> > + * efi_tcg2_measure_efi_app_exit() - measure efi app exit
> > + *
> > + * Return: status code
> > + */
> > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void)
> > +{
> > + efi_status_t ret;
> > + struct udevice *dev;
> > +
> > + ret = platform_get_tpm2_device(&dev);
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> > +
> > + ret = tcg2_measure_event(dev, 4, EV_EFI_ACTION,
> > + strlen(EFI_RETURNING_FROM_EFI_APPLICATION),
>
> Do we need a NUL terminator on this string or not?
No, TCG spec says
"the actual log entries SHALL NOT include the quote characters
or a NUL terminator."
Thanks,
Masahisa Kojima
>
>
> Regards
> /Ilias
Re: [PATCH 1/5] efi_loader: increase eventlog buffer size
On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt wrote: > > > > On 7/7/21 3:36 PM, Masahisa Kojima wrote: > > This is a preperation to add eventlog support > > described in TCG PC Client PFP spec. > > > > Signed-off-by: Masahisa Kojima > > --- > > lib/efi_loader/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index b2ab48a048..a87bf3cc98 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL > > config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE > > int "EFI_TCG2_PROTOCOL EventLog size" > > depends on EFI_TCG2_PROTOCOL > > - default 4096 > > + default 16384 > > I found this text in EDK II: > > Minimum length(in bytes) of the system preboot TCG event log area(LAML) > --- > > For PC Client Implementation spec up to and including 1.2 the minimum > log size is 64KB. (SecurityPkg/SecurityPkg.dec) Thank you for your feedback. I have not checked this. TCG spec also says "The Log Area Minimum Length for the TCG event log MUST be at least 64KB." in ACPI chapter. I will update to set 64KB as default. Thanks, Masahisa Kojima > > Why should ours be smaller? > > Best regards > > Heinrich > > > help > > Define the size of the EventLog for EFI_TCG2_PROTOCOL. Note > > that > > this is going to be allocated twice. One for the eventlog it > > self > >
[PATCH] arm: omap4: Disable USB_TTY and related options
The usbtty functionality is not currently used on these two platforms, disable it. Cc: Lokesh Vutla Signed-off-by: Tom Rini --- configs/omap4_panda_defconfig | 1 - configs/omap4_sdp4430_defconfig | 1 - include/configs/ti_omap4_common.h | 6 -- 3 files changed, 8 deletions(-) diff --git a/configs/omap4_panda_defconfig b/configs/omap4_panda_defconfig index 08dc3552c828..9e99e8bc6991 100644 --- a/configs/omap4_panda_defconfig +++ b/configs/omap4_panda_defconfig @@ -39,7 +39,6 @@ CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_MUSB_UDC=y CONFIG_USB_OMAP3=y CONFIG_USB_GADGET=y CONFIG_USB_HOST_ETHER=y diff --git a/configs/omap4_sdp4430_defconfig b/configs/omap4_sdp4430_defconfig index f90b28142880..fd93dc5c785d 100644 --- a/configs/omap4_sdp4430_defconfig +++ b/configs/omap4_sdp4430_defconfig @@ -39,7 +39,6 @@ CONFIG_CONS_INDEX=3 CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y -CONFIG_USB_MUSB_UDC=y CONFIG_USB_OMAP3=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index 1e316227aaa2..d0eddcce1bb3 100644 --- a/include/configs/ti_omap4_common.h +++ b/include/configs/ti_omap4_common.h @@ -51,12 +51,6 @@ #define CONFIG_TWL6030_POWER 1 #endif -/* USB */ - -/* USB device configuration */ -#define CONFIG_USB_DEVICE 1 -#define CONFIG_USB_TTY 1 - /* * Environment setup */ -- 2.17.1
[PATCH 2/2] board: sifive: unmatched: reset USB hub, PCIe-USB bridge, and ULPI device in SPL
Ensure USB hub, PCIe-USB bridge, and ULPI device to be reset
even if the rebooting is without power-cycling.
Signed-off-by: Vincent Chen
---
board/sifive/unmatched/spl.c | 36
1 file changed, 36 insertions(+)
diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index b598f9f..d566327 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -16,6 +16,9 @@
#include
#include
+#define UBRDG_RESETSIFIVE_GENERIC_GPIO_NR(0, 7)
+#define ULPI_RESET SIFIVE_GENERIC_GPIO_NR(0, 9)
+#define UHUB_RESET SIFIVE_GENERIC_GPIO_NR(0, 11)
#define GEM_PHY_RESET SIFIVE_GENERIC_GPIO_NR(0, 12)
#define MODE_SELECT_REG0x1000
@@ -61,6 +64,21 @@ static inline int spl_gemgxl_init(void)
return ret;
}
+static inline int spl_usb_pcie_bridge_init(void)
+{
+ return spl_reset_device_by_gpio("usb_pcie_bridge_reset", UBRDG_RESET,
3000);
+}
+
+static inline int spl_usb_hub_init(void)
+{
+ return spl_reset_device_by_gpio("usb_hub_reset", UHUB_RESET, 100);
+}
+
+static inline int spl_ulpi_init(void)
+{
+ return spl_reset_device_by_gpio("ulpi_reset", ULPI_RESET, 1);
+}
+
int spl_board_init_f(void)
{
int ret;
@@ -77,6 +95,24 @@ int spl_board_init_f(void)
goto end;
}
+ ret = spl_usb_pcie_bridge_init();
+ if (ret) {
+ debug("USB Bridge (ASM1042A) init failed: %d\n", ret);
+ goto end;
+ }
+
+ ret = spl_usb_hub_init();
+ if (ret) {
+ debug("USB Hub (ASM1074) init failed: %d\n", ret);
+ goto end;
+ }
+
+ ret = spl_ulpi_init();
+ if (ret) {
+ debug("USB 2.0 PHY (USB3320C) init failed: %d\n", ret);
+ goto end;
+ }
+
end:
return ret;
}
--
2.7.4
[PATCH 1/2] board: sifive: unmatched: refine GEMGXL initialized function in SPL
Create a new function spl_reset_device_by_gpio to reset the device
whose reset pin is connected to the GPIO. Then, using this function
to initialize GEMGXL.
Signed-off-by: Vincent Chen
---
board/sifive/unmatched/spl.c | 58 +---
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index 5e1333b..b598f9f 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -22,43 +22,63 @@
#define MODE_SELECT_SD 0xb
#define MODE_SELECT_MASK GENMASK(3, 0)
-int spl_board_init_f(void)
+static inline int spl_reset_device_by_gpio(const char *label, int pin, int
low_width)
{
int ret;
- ret = spl_soc_init();
+ ret = gpio_request(pin, label);
if (ret) {
- debug("HiFive Unmatched FU740 SPL init failed: %d\n", ret);
+ debug("%s gpio request failed: %d\n", label, ret);
+ return ret;
+ }
+
+ ret = gpio_direction_output(pin, 1);
+ if (ret) {
+ debug("%s gpio direction set failed: %d\n", label, ret);
return ret;
}
+ udelay(1);
+
+ gpio_set_value(pin, 0);
+ udelay(low_width);
+ gpio_set_value(pin, 1);
+
+ return ret;
+}
+
+static inline int spl_gemgxl_init(void)
+{
+ int ret;
/*
* GEMGXL init VSC8541 PHY reset sequence;
* leave pull-down active for 2ms
*/
udelay(2000);
- ret = gpio_request(GEM_PHY_RESET, "gem_phy_reset");
+ ret = spl_reset_device_by_gpio("gem_phy_reset", GEM_PHY_RESET, 1);
+ mdelay(15);
+
+ return ret;
+}
+
+int spl_board_init_f(void)
+{
+ int ret;
+
+ ret = spl_soc_init();
if (ret) {
- debug("gem_phy_reset gpio request failed: %d\n", ret);
- return ret;
+ debug("HiFive Unmatched FU740 SPL init failed: %d\n", ret);
+ goto end;
}
- /* Set GPIO 12 (PHY NRESET) */
- ret = gpio_direction_output(GEM_PHY_RESET, 1);
+ ret = spl_gemgxl_init();
if (ret) {
- debug("gem_phy_reset gpio direction set failed: %d\n", ret);
- return ret;
+ debug("Gigabit ethernet PHY (VSC8541) init failed: %d\n", ret);
+ goto end;
}
- udelay(1);
-
- /* Reset PHY again to enter unmanaged mode */
- gpio_set_value(GEM_PHY_RESET, 0);
- udelay(1);
- gpio_set_value(GEM_PHY_RESET, 1);
- mdelay(15);
-
- return 0;
+end:
+ return ret;
}
u32 spl_boot_device(void)
--
2.7.4
[PATCH 0/2] board: sifive: unmatched: reset multiple devices in SPL
In SiFive unmatched board, the reset of the USB hub, PCIe-USB bridge, and ULPI rely on the power-cycling. However, sometimes the rebooting is without power-cycling. To ensure these devices will be reset in each rebooting, here always reset these devices in the spl_board_init_f(). In addition, because the reset pint of these four devices incluing GEMGXL connects to the GPIO, the 1st patch creates a new wrapper, spl_reset_device_by_gpio(), to address the GPIO operation during the reset. Vincent Chen (2): board: sifive: unmatched: refine GEMGXL initialized function in SPL board: sifive: unmatched: reset USB hub, PCIe-USB bridge, and ULPI device in SPL board/sifive/unmatched/spl.c | 90 +++- 1 file changed, 73 insertions(+), 17 deletions(-) -- 2.7.4
Re: [PATCH 2/2] board: stemmy: Copy atags for booting downstream/vendor kernel
On Wed, Jul 7, 2021 at 12:59 PM Stephan Gerhold wrote: > The U-Boot "stemmy" board is mainly intended to simplify booting > mainline Linux on various smartphones from Samsung based on ST-Ericsson > Ux500. While the mainline kernel is working great, there are still some > features missing there. In particular, it is currently not possible to > charge the battery when using the mainline kernel. > > This means that it is still necessary to boot the downstream/vendor > kernel from Samsung sometimes to charge the device. That kernel is > ancient, still uses board files + ATAGS instead of device trees and > relies on a strange very long kernel command line hardcoded in the > Samsung bootloader. > > Actually, since mainline is booted with device trees there is a very > simple way to make the old downstream kernel work as well: We can > simply take most of the ATAGS passed to U-Boot from the Samsung > bootloader and copy them as-is when booting a kernel without device > tree. That way the long command line and other needed ATAGS are copied > as-is without having to bother with them. > > The only exception is the ATAG_INITRD - since the initrd is loaded > by U-Boot, the atag for that should be generated in U-Boot so it points > to the correct address. All other ATAGS are copied as-is and not > generated in U-Boot. > > Also use the chance and provide a serial# for U-Boot by parsing the > ATAG_SERIAL that is also passed by the Samsung bootloader. > > Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH u-boot-dm + u-boot-spi v4 04/10] mtd: spi-nor: allow registering multiple MTDs when DM is enabled
Hi Marek,
I found that this changes the mtd device name and makes 'mtdparts'
doesn't work on my developerbox platform.
Before this change,
---
=> sf probe
SF: Detected mx66u51235f with page size 256 Bytes, erase size 4 KiB,
total 64 MiB
=> mtd list
List of MTD devices:
* nor1
- type: NOR flash
- block size: 0x1000 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "nor1"
- 0x-0x0007 : "BootStrap-BL1"
- 0x0007-0x0010 : "Flash-Writer"
- 0x0010-0x0018 : "SCP-BL2"
- 0x0018-0x001f8000 : "FIP-TFA"
- 0x001f8000-0x0020 : "Stg2-Tables"
- 0x0020-0x0040 : "EDK2"
- 0x0040-0x0050 : "UEFI-Vars"
- 0x0050-0x0070 : "OPTEE"
- 0x0070-0x0080 : "UBoot-Env"
- 0x0080-0x0090 : "U-Boot"
- 0x0090-0x0400 : "Free"
=>
---
after this change,
---
=> sf probe
SF: Detected mx66u51235f with page size 256 Bytes, erase size 4 KiB,
total 64 MiB
=> mtd list
Could not find a valid device for nor1
List of MTD devices:
* mx66u51235f
- device: spi-flash@0
- parent: spi@5480
- driver: jedec_spi_nor
- path: /spi@5480/spi-flash@0
- type: NOR flash
- block size: 0x1000 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66u51235f"
---
I think I should update CONFIG_MTDIDS_DEFAULT and CONFIG_MTDPARTS_DEFAULT.
But before that, I would like to confirm that this is an intended
change, and what should I do. (replace nor1 with mx66u51235f ?)
Thank you,
2021年5月26日(水) 21:10 Marek Behún :
>
> Currently when the SPI_FLASH_MTD config option is enabled, only one SPI
> can be registered as MTD at any time - it is the last one probed (since
> with old non-DM model only one SPI NOR could be probed at any time).
>
> When DM is enabled, allow for registering multiple SPI NORs as MTDs by
> utilizing the nor->mtd structure, which is filled in by spi_nor_scan
> anyway, instead of filling a separate struct mtd_info.
>
> Signed-off-by: Marek Behún
> Reviewed-by: Pali Rohár
> Reviewed-by: Miquel Raynal
> Tested-by: Patrice Chotard
> Cc: Jagan Teki
> Cc: Priyanka Jain
> Cc: Simon Glass
> Cc: Heiko Schocher
> Cc: Jagan Teki
> Cc: Patrick Delaunay
> ---
> drivers/mtd/spi/sf_internal.h | 4 ++--
> drivers/mtd/spi/sf_mtd.c | 18 +-
> drivers/mtd/spi/sf_probe.c| 6 --
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 786301ba4a..0b63e1bfc2 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -81,14 +81,14 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash
> *flash);
>
> #if CONFIG_IS_ENABLED(SPI_FLASH_MTD)
> int spi_flash_mtd_register(struct spi_flash *flash);
> -void spi_flash_mtd_unregister(void);
> +void spi_flash_mtd_unregister(struct spi_flash *flash);
> #else
> static inline int spi_flash_mtd_register(struct spi_flash *flash)
> {
> return 0;
> }
>
> -static inline void spi_flash_mtd_unregister(void)
> +static inline void spi_flash_mtd_unregister(struct spi_flash *flash)
> {
> }
> #endif
> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> index 987fac2501..94854fbfc4 100644
> --- a/drivers/mtd/spi/sf_mtd.c
> +++ b/drivers/mtd/spi/sf_mtd.c
> @@ -10,6 +10,20 @@
> #include
> #include
>
> +#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
> +
> +int spi_flash_mtd_register(struct spi_flash *flash)
> +{
> + return add_mtd_device(&flash->mtd);
> +}
> +
> +void spi_flash_mtd_unregister(struct spi_flash *flash)
> +{
> + del_mtd_device(&flash->mtd);
> +}
> +
> +#else /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */
> +
> static struct mtd_info sf_mtd_info;
> static bool sf_mtd_registered;
> static char sf_mtd_name[8];
> @@ -123,7 +137,7 @@ int spi_flash_mtd_register(struct spi_flash *flash)
> return ret;
> }
>
> -void spi_flash_mtd_unregister(void)
> +void spi_flash_mtd_unregister(struct spi_flash *flash)
> {
> int ret;
>
> @@ -146,3 +160,5 @@ void spi_flash_mtd_unregister(void)
> printf("Failed to unregister MTD %s and the spi_flash object is going
> away: you're in deep trouble!",
>sf_mtd_info.name);
> }
> +
> +#endif /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index 3befbe91ca..7edb8759fd 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum,
> unsigned int cs,
> void spi_flash_free(struct spi_flash *flash)
> {
> if (CONFIG_IS_ENABLED(SPI_FLASH_MTD))
> - spi_flash_mtd_unregister();
> + spi_flash_mtd_unregister(flash);
>
> spi_free_slave(flash->spi);
> free(flash);
> @@ -150,
Re: [PATCH 1/2] board: stemmy: Parse atags to get available memory
On Wed, Jul 7, 2021 at 12:59 PM Stephan Gerhold wrote: > At the moment the "stemmy" board attempts to detect the RAM size with > a simple memory test (get_ram_size()). Unfortunately, this does not work > correctly for devices with 768 MiB RAM (e.g. Samsung Galaxy Ace 2 > (GT-I8160), "codina"). Reading/writing memory after the 768 MiB RAM > succeeds but actually overwrites some earlier parts of the memory. > > For U-Boot this does not result in any major problems, but on Linux > this will eventually lead to strange crashes because of the memory > corruption. > > Since the "stemmy" U-Boot port is designed to be chainloaded from > the original Samsung bootloader, the most reliable way to get the > available amount of RAM is to look at the ATAGS passed by the Samsung > bootloader. Fortunately, the header used to generate ATAGS in U-Boot > (asm/setup.h) can also be easily used to parse them. > > Also clarify and simplify stemmy.h a bit to make it more clear where > some of the magic values in there are actually coming from. > > Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij > - Samsung Galaxy S III mini (GT-I8190)"golden" > - Samsung Galaxy S Advance (GT-I9070) "janice" > - Samsung Galaxy Xcover 2 (GT-S7710) "skomer" > + - Samsung Galaxy Ace 2 (GT-I8160) "codina" I have also used Stemmy U-boot successfully on Samsung Galaxy Beam (GT-I8530) "gavini" Samsung Galaxy Amp (SGH-I407) "kyle" Yours, Linus Walleij
Re: [PATCH 0/4] Add support for eMMC on ST-Ericsson Ux500(v2)
On Tue, Jul 6, 2021 at 4:55 PM Stephan Gerhold wrote: > This patch series adds support for the eMMC on ST-Ericsson Ux500: > > 1. Some minor fixes+cleanup for the arm_pl180_mmci driver. > 3. Add the necessary configuration for ST-Ericsson Ux500v2. > > This was tested on the u8500 "stemmy" board that is already present > in U-Boot. The series: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 3/3] usb: musb-new: Add glue driver for ST-Ericsson Ux500
On Mon, Jul 5, 2021 at 6:28 PM Stephan Gerhold wrote: > The ST-Ericsson DB8500 SoC contains a MUSB OTG controller which > supports both host and gadget mode. For some reason there is > nothing special about it - add a simple glue driver for Ux500 > that literally just sets up MUSB together with a generic PHY. > There are no SoC-specific registers etc needed to make USB work. > > The new Ux500 glue driver is only tested to work with DM_USB > and DM_USB_GADGET. Both host and gadget mode work fine on > the u8500 "stemmy" board that is already present in U-Boot. > > Cc: Linus Walleij > Signed-off-by: Stephan Gerhold FWIW: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 2/3] phy: Add driver for ST-Ericsson AB8500 USB PHY
On Mon, Jul 5, 2021 at 6:28 PM Stephan Gerhold wrote: > The AB8500 PMIC contains an USB PHY that needs to be set up in > device or host mode to make USB work properly. Add a simple driver > for the generic PHY uclass that allows enabling it. > > The if (CONFIG_IS_ENABLED(USB_MUSB_HOST)) might be a bit strange. > The USB PHY must be configured in either host or device mode and > somehow the USB PHY driver must be made aware of the mode. > > Actually, the MUSB driver used together with this PHY does not > support dynamic selection of host/device mode in U-Boot at the moment. > Therefore, one very simple approach that works fine is to select > the mode to configure at compile time. When the MUSB driver is > configured in host mode the PHY is configured in host mode, and > similarly when the MUSB driver is configured in device/gadget mode. > > Cc: Linus Walleij > Signed-off-by: Stephan Gerhold FWIW: Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] x86: Drop _X86EMU_env definition when CONFIG_BIOSEMU is used
Hi Simon, On Thu, Jul 8, 2021 at 1:35 AM Simon Glass wrote: > > Hi Bin, > > On Wed, 7 Jul 2021 at 01:36, Bin Meng wrote: > > > > With x86 we can execute an option ROM either natively or using the > > x86 emulator (if enabled with CONFIG_BIOSEMU). Both of these share > > the _X86EMU_env variable, with the native code using it to hold > > register state during interrupt processing. > > > > At present, in 32-bit U-Boot, the variable is declared twice, once > > in common code and once in code only compiled with CONFIG_BIOSEMU. > > > > With GCC 11 this causes a 'multiple definitions' error on boards > > with CONFIG_BIOSEMU. > > > > Drop the emulator definition when CONFIG_BIOSEMU is used. > > > > Signed-off-by: Bin Meng > > --- > > > > arch/x86/lib/bios.c | 2 ++ > > 1 file changed, 2 insertions(+) > > This seems a bit hacky. Should we define a new Kconfig that both use, > then put this declaration in a common file? Yes, that's what I thought so. We can do this later. Currently this is to unblock the GCC 11 CI testing. Regards, Bin
Re: Please pull u-boot-dm
On Wed, Jul 07, 2021 at 09:58:47AM -0600, Simon Glass wrote: > Hi Tom, > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8087 > > > > The following changes since commit 1311dd37ecf476be041d0452d4ee38619aadd5de: > > Merge branch '2021-07-01-update-CI-containers' (2021-07-05 15:29:44 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-6jul21 > > for you to fetch changes up to 880e4768c20b99b1f9a50f35c180f8522dd82c9a: > > tools: Fix default target compile tools in Python tools (2021-07-06 > 10:38:03 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v4 8/8] test: add first autoboot unit tests
This adds tests for the crypt-based and plain SHA256-based password hashing
algorithms in the autoboot flow.
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
Changes in v4:
Add another test with `bootstopusesha256` unset
common/Kconfig.boot | 2 +-
common/console.c| 5 +++
configs/sandbox_defconfig | 13 +-
include/console.h | 17 +++
include/test/common.h | 15 +++
include/test/suites.h | 1 +
test/Makefile | 1 +
test/cmd_ut.c | 1 +
test/common/Makefile| 3 ++
test/common/cmd_ut_common.c | 22 +
test/common/test_autoboot.c | 90 +
11 files changed, 168 insertions(+), 2 deletions(-)
create mode 100644 include/test/common.h
create mode 100644 test/common/Makefile
create mode 100644 test/common/cmd_ut_common.c
create mode 100644 test/common/test_autoboot.c
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 764656720a..d2a075d754 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -906,7 +906,7 @@ config AUTOBOOT_STOP_STR_CRYPT
and saved in the environment variable "bootstopkeycrypt".
config AUTOBOOT_STOP_STR_SHA256
- string "Stop autobooting via SHA256 encrypted password"
+ string "Stop autobooting via SHA256 hashed password"
depends on AUTOBOOT_STOP_STR_ENABLE
help
This option adds the feature to only stop the autobooting,
diff --git a/common/console.c b/common/console.c
index 73edb28799..0013d183ae 100644
--- a/common/console.c
+++ b/common/console.c
@@ -773,6 +773,11 @@ int console_record_avail(void)
return membuff_avail((struct membuff *)&gd->console_out);
}
+int console_in_puts(const char *str)
+{
+ return membuff_put((struct membuff *)&gd->console_in, str, strlen(str));
+}
+
#endif
/* test if ctrl-c was pressed */
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index f16e2d5d23..45eda93915 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -287,6 +287,17 @@ CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
+CONFIG_CRYPT_PW=y
+CONFIG_CRYPT_PW_SHA256=y
+CONFIG_CRYPT_PW_SHA512=y
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Enter password \"a\" in %d seconds to stop autoboot\n"
+CONFIG_AUTOBOOT_ENCRYPTION=y
+CONFIG_AUTOBOOT_STOP_STR_ENABLE=y
+# default password "a"
+CONFIG_AUTOBOOT_STOP_STR_CRYPT="$5$rounds=64$HrpE65IkB8CM5nCL$BKT3QdF98Bo8fJpTr9tjZLZQyzqPASBY20xuK5Rent9"
+CONFIG_AUTOBOOT_NEVER_TIMEOUT=y
+CONFIG_AUTOBOOT_SHA256_FALLBACK=y
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
-CONFIG_UT_DM=y
+CONFIG_UT_DM=y
\ No newline at end of file
diff --git a/include/console.h b/include/console.h
index f848bcbf03..b182440fcd 100644
--- a/include/console.h
+++ b/include/console.h
@@ -83,6 +83,17 @@ int console_record_readline(char *str, int maxlen);
* @return available bytes (0 if empty)
*/
int console_record_avail(void);
+
+/**
+ * console_in_puts() - Write a string to the console input buffer
+ *
+ * This writes the given string to the console_in buffer which will then be
+ * returned if a function calls e.g. `getc()`
+ *
+ * @str: the string to write
+ * @return the number of bytes added
+ */
+int console_in_puts(const char *str);
#else
static inline int console_record_init(void)
{
@@ -114,6 +125,12 @@ static inline int console_record_avail(void)
return 0;
}
+static inline int console_in_puts(const char *str)
+{
+ /* There is never anything written */
+ return 0;
+}
+
#endif /* !CONFIG_CONSOLE_RECORD */
/**
diff --git a/include/test/common.h b/include/test/common.h
new file mode 100644
index 00..81260d06ad
--- /dev/null
+++ b/include/test/common.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 Heinrich Schuchardt
+ * Copyright (c) 2021 Steffen Jaeckel
+ */
+
+#ifndef __TEST_COMMON_H__
+#define __TEST_COMMON_H__
+
+#include
+
+/* Declare a new common function test */
+#define COMMON_TEST(_name, _flags) UNIT_TEST(_name, _flags, common_test)
+
+#endif /* __TEST_COMMON_H__ */
diff --git a/include/test/suites.h b/include/test/suites.h
index 80b41f188c..d35cd83a4e 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -31,6 +31,7 @@ int do_ut_addrmap(struct cmd_tbl *cmdtp, int flag, int argc,
int do_ut_bootm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
int do_ut_bloblist(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[]);
+int do_ut_common(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[]);
int do_ut_compression(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[]);
int do_ut_dm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
diff --git a/test/Makefile b/test/Makefile
index a26e915e05..afc7864a54 100644
--- a/test/Makefile
+++ b/test/Makefile
@@ -20
[PATCH v4 7/8] common: add support to fallback to plain SHA256
In case crypt-based hashing is enabled this will be the default mechanism
that is used. If a user wants to have support for both, the environment
variable `bootstopusesha256` can be set to `true` to allow plain SHA256
based hashing of the password.
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
Changes in v4:
Take review comments into account
common/Kconfig.boot | 8
common/autoboot.c | 22 +-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index d19bc32836..764656720a 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -834,6 +834,14 @@ config AUTOBOOT_ENCRYPTION
This provides a way to ship a secure production device which can also
be accessed at the U-Boot command line.
+config AUTOBOOT_SHA256_FALLBACK
+ bool "Allow fallback from crypt-hashed password to sha256"
+ depends on AUTOBOOT_ENCRYPTION && CRYPT_PW
+ help
+ This option adds support to fall back from crypt-hashed
+ passwords to checking a SHA256 hashed password in case the
+ 'bootstopusesha256' environment variable is set to 'true'.
+
config AUTOBOOT_DELAY_STR
string "Delay autobooting via specific input key / string"
depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION
diff --git a/common/autoboot.c b/common/autoboot.c
index 35ef526c42..8b9e9aa878 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -306,6 +306,26 @@ static void flush_stdin(void)
(void)getchar();
}
+/**
+ * fallback_to_sha256() - check whether we should fall back to sha256
+ *password checking
+ *
+ * This checks for the environment variable `bootstopusesha256` in case
+ * sha256-fallback has been enabled via the config setting
+ * `AUTOBOOT_SHA256_FALLBACK`.
+ *
+ * @return `false` if we must not fall-back, `true` if plain sha256 should be
tried
+ */
+static bool fallback_to_sha256(void)
+{
+ if (IS_ENABLED(CONFIG_AUTOBOOT_SHA256_FALLBACK))
+ return env_get_yesno("bootstopusesha256") == 1;
+ else if (IS_ENABLED(CONFIG_CRYPT_PW))
+ return false;
+ else
+ return true;
+}
+
/***
* Watch for 'delay' seconds for autoboot stop or autoboot delay string.
* returns: 0 - no key string, allow autoboot 1 - got key string, abort
@@ -326,7 +346,7 @@ static int abortboot_key_sequence(int bootdelay)
# endif
if (IS_ENABLED(CONFIG_AUTOBOOT_ENCRYPTION)) {
- if (IS_ENABLED(CONFIG_CRYPT_PW))
+ if (IS_ENABLED(CONFIG_CRYPT_PW) && !fallback_to_sha256())
abort = passwd_abort_crypt(etime);
else
abort = passwd_abort_sha256(etime);
--
2.32.0
[PATCH v4 6/8] common: add AUTOBOOT_FLUSH_STDIN option
The key-sequence based unlock mechanisms are sensitive to junk symbols
that could have been sent to stdin and are still waiting to be retrieved.
Enabling this option will read all symbols off stdin before displaying the
autoboot prompt (and starting to read the password from stdin).
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
(no changes since v1)
common/Kconfig.boot | 9 +
common/autoboot.c | 11 +++
2 files changed, 20 insertions(+)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index e70dcf17cb..d19bc32836 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -790,6 +790,15 @@ config AUTOBOOT_KEYED
U-Boot automatic booting process and bring the device
to the U-Boot prompt for user input.
+config AUTOBOOT_FLUSH_STDIN
+ bool "Enable flushing stdin before starting to read the password"
+ depends on AUTOBOOT_KEYED && !SANDBOX
+ help
+ When this option is enabled stdin buffer will be flushed before
+ starting to read the password.
+ This can't be enabled for the sandbox as flushing stdin would
+ break the autoboot unit tests.
+
config AUTOBOOT_PROMPT
string "Autoboot stop prompt"
depends on AUTOBOOT_KEYED
diff --git a/common/autoboot.c b/common/autoboot.c
index 2564ef8a56..35ef526c42 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -297,6 +297,15 @@ static int passwd_abort_key(uint64_t etime)
return abort;
}
+/**
+ * flush_stdin() - drops all pending characters from stdin
+ */
+static void flush_stdin(void)
+{
+ while (tstc())
+ (void)getchar();
+}
+
/***
* Watch for 'delay' seconds for autoboot stop or autoboot delay string.
* returns: 0 - no key string, allow autoboot 1 - got key string, abort
@@ -306,6 +315,8 @@ static int abortboot_key_sequence(int bootdelay)
int abort;
uint64_t etime = endtick(bootdelay);
+ if (IS_ENABLED(CONFIG_AUTOBOOT_FLUSH_STDIN))
+ flush_stdin();
# ifdef CONFIG_AUTOBOOT_PROMPT
/*
* CONFIG_AUTOBOOT_PROMPT includes the %d for all boards.
--
2.32.0
[PATCH v4 5/8] common: allow disabling of timeout for password entry
In case a user has to enter a complicated password it is sometimes
desireable to give the user more time than the default timeout.
Enabling this feature will disable the timeout entirely in case the user
presses the key before entering any other character.
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
(no changes since v1)
common/Kconfig.boot | 8
common/autoboot.c | 12 +++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 410d117cdd..e70dcf17cb 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -859,6 +859,14 @@ config AUTOBOOT_KEYED_CTRLC
Setting this variable provides an escape sequence from the
limited "password" strings.
+config AUTOBOOT_NEVER_TIMEOUT
+ bool "Make the password entry never time-out"
+ depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION && CRYPT_PW
+ help
+ This option removes the timeout from the password entry
+ when the user first presses the key before entering
+ any other character.
+
config AUTOBOOT_STOP_STR_ENABLE
bool "Enable fixed string to stop autobooting"
depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION
diff --git a/common/autoboot.c b/common/autoboot.c
index 832ef7c78c..2564ef8a56 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -63,6 +63,10 @@ static int menukey;
* or
* the config value CONFIG_AUTOBOOT_STOP_STR_CRYPT
*
+ * In case the config value CONFIG_AUTOBOOT_NEVER_TIMEOUT has been enabled
+ * this function never times out if the user presses the key
+ * before starting to enter the password.
+ *
* @etime: Timeout value ticks (stop when get_ticks() reachs this)
* @return 0 if autoboot should continue, 1 if it should stop
*/
@@ -72,6 +76,7 @@ static int passwd_abort_crypt(uint64_t etime)
char presskey[DELAY_STOP_STR_MAX_LENGTH];
u_int presskey_len = 0;
int abort = 0;
+ int never_timeout = 0;
int err;
if (IS_ENABLED(CONFIG_AUTOBOOT_STOP_STR_ENABLE) && !crypt_env_str)
@@ -91,6 +96,11 @@ static int passwd_abort_crypt(uint64_t etime)
if ((presskey[presskey_len] == '\r') ||
(presskey[presskey_len] == '\n')) {
+ if (IS_ENABLED(CONFIG_AUTOBOOT_NEVER_TIMEOUT) &&
+ !presskey_len) {
+ never_timeout = 1;
+ continue;
+ }
presskey[presskey_len] = '\0';
err = crypt_compare(crypt_env_str, presskey,
&abort);
@@ -104,7 +114,7 @@ static int passwd_abort_crypt(uint64_t etime)
presskey_len++;
}
}
- } while (get_ticks() <= etime);
+ } while (never_timeout || get_ticks() <= etime);
return abort;
}
--
2.32.0
[PATCH v4 4/8] common: Rename macro appropriately
While doing code-review internally this got nitpicked by 2 reviewers, so
I decided to include this here.
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
(no changes since v1)
common/autoboot.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/autoboot.c b/common/autoboot.c
index 107fb1533d..832ef7c78c 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -27,7 +27,7 @@
DECLARE_GLOBAL_DATA_PTR;
-#define MAX_DELAY_STOP_STR 64
+#define DELAY_STOP_STR_MAX_LENGTH 64
#ifndef DEBUG_BOOTKEYS
#define DEBUG_BOOTKEYS 0
@@ -69,7 +69,7 @@ static int menukey;
static int passwd_abort_crypt(uint64_t etime)
{
const char *crypt_env_str = env_get("bootstopkeycrypt");
- char presskey[MAX_DELAY_STOP_STR];
+ char presskey[DELAY_STOP_STR_MAX_LENGTH];
u_int presskey_len = 0;
int abort = 0;
int err;
@@ -150,9 +150,9 @@ static int passwd_abort_sha256(uint64_t etime)
if (sha_env_str == NULL)
sha_env_str = CONFIG_AUTOBOOT_STOP_STR_SHA256;
- presskey = malloc_cache_aligned(MAX_DELAY_STOP_STR);
+ presskey = malloc_cache_aligned(DELAY_STOP_STR_MAX_LENGTH);
c = strstr(sha_env_str, ":");
- if (c && (c - sha_env_str < MAX_DELAY_STOP_STR)) {
+ if (c && (c - sha_env_str < DELAY_STOP_STR_MAX_LENGTH)) {
/* preload presskey with salt */
memcpy(presskey, sha_env_str, c - sha_env_str);
presskey_len = c - sha_env_str;
@@ -179,7 +179,7 @@ static int passwd_abort_sha256(uint64_t etime)
do {
if (tstc()) {
/* Check for input string overflow */
- if (presskey_len >= MAX_DELAY_STOP_STR) {
+ if (presskey_len >= DELAY_STOP_STR_MAX_LENGTH) {
free(presskey);
free(sha);
return 0;
@@ -223,7 +223,7 @@ static int passwd_abort_key(uint64_t etime)
{ .str = env_get("bootstopkey"), .retry = 0 },
};
- char presskey[MAX_DELAY_STOP_STR];
+ char presskey[DELAY_STOP_STR_MAX_LENGTH];
int presskey_len = 0;
int presskey_max = 0;
int i;
@@ -240,8 +240,8 @@ static int passwd_abort_key(uint64_t etime)
for (i = 0; i < sizeof(delaykey) / sizeof(delaykey[0]); i++) {
delaykey[i].len = delaykey[i].str == NULL ?
0 : strlen(delaykey[i].str);
- delaykey[i].len = delaykey[i].len > MAX_DELAY_STOP_STR ?
- MAX_DELAY_STOP_STR : delaykey[i].len;
+ delaykey[i].len = delaykey[i].len > DELAY_STOP_STR_MAX_LENGTH ?
+ DELAY_STOP_STR_MAX_LENGTH : delaykey[i].len;
presskey_max = presskey_max > delaykey[i].len ?
presskey_max : delaykey[i].len;
--
2.32.0
[PATCH v4 3/8] common: integrate crypt-based passwords
Hook into the autoboot flow as an alternative to the existing
mechanisms.
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
(no changes since v1)
common/Kconfig.boot | 38 ++---
common/autoboot.c | 81 -
2 files changed, 105 insertions(+), 14 deletions(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 89a3161f1f..410d117cdd 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -811,10 +811,17 @@ config AUTOBOOT_ENCRYPTION
depends on AUTOBOOT_KEYED
help
This option allows a string to be entered into U-Boot to stop the
- autoboot. The string itself is hashed and compared against the hash
- in the environment variable 'bootstopkeysha256'. If it matches then
- boot stops and a command-line prompt is presented.
-
+ autoboot.
+ The behavior depends whether CONFIG_CRYPT_PW from lib is enabled
+ or not.
+ In case CONFIG_CRYPT_PW is enabled, the string will be forwarded
+ to the crypt-based functionality and be compared against the
+ string in the environment variable 'bootstopkeycrypt'.
+ In case CONFIG_CRYPT_PW is disabled the string itself is hashed
+ and compared against the hash in the environment variable
+ 'bootstopkeysha256'.
+ If it matches in either case then boot stops and
+ a command-line prompt is presented.
This provides a way to ship a secure production device which can also
be accessed at the U-Boot command line.
@@ -852,9 +859,30 @@ config AUTOBOOT_KEYED_CTRLC
Setting this variable provides an escape sequence from the
limited "password" strings.
+config AUTOBOOT_STOP_STR_ENABLE
+ bool "Enable fixed string to stop autobooting"
+ depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION
+ help
+ This option enables the feature to add a fixed stop
+ string that is defined at compile time.
+ In every case it will be tried to load the stop
+ string from the environment.
+ In case this is enabled and there is no stop string
+ in the environment, this will be used as default value.
+
+config AUTOBOOT_STOP_STR_CRYPT
+ string "Stop autobooting via crypt-hashed password"
+ depends on AUTOBOOT_STOP_STR_ENABLE && CRYPT_PW
+ help
+ This option adds the feature to only stop the autobooting,
+ and therefore boot into the U-Boot prompt, when the input
+ string / password matches a values that is hashed via
+ one of the supported crypt-style password hashing options
+ and saved in the environment variable "bootstopkeycrypt".
+
config AUTOBOOT_STOP_STR_SHA256
string "Stop autobooting via SHA256 encrypted password"
- depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION
+ depends on AUTOBOOT_STOP_STR_ENABLE
help
This option adds the feature to only stop the autobooting,
and therefore boot into the U-Boot prompt, when the input
diff --git a/common/autoboot.c b/common/autoboot.c
index b42148c729..107fb1533d 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -38,10 +39,11 @@ DECLARE_GLOBAL_DATA_PTR;
static int stored_bootdelay;
static int menukey;
-#ifdef CONFIG_AUTOBOOT_ENCRYPTION
-#define AUTOBOOT_STOP_STR_SHA256 CONFIG_AUTOBOOT_STOP_STR_SHA256
-#else
-#define AUTOBOOT_STOP_STR_SHA256 ""
+#if !defined(CONFIG_AUTOBOOT_STOP_STR_CRYPT)
+#define CONFIG_AUTOBOOT_STOP_STR_CRYPT ""
+#endif
+#if !defined(CONFIG_AUTOBOOT_STOP_STR_SHA256)
+#define CONFIG_AUTOBOOT_STOP_STR_SHA256 ""
#endif
#ifdef CONFIG_AUTOBOOT_USE_MENUKEY
@@ -50,6 +52,63 @@ static int menukey;
#define AUTOBOOT_MENUKEY 0
#endif
+/**
+ * passwd_abort_crypt() - check for a crypt-style hashed key sequence to abort
booting
+ *
+ * This checks for the user entering a password within a given time.
+ *
+ * The entered password is hashed via one of the crypt-style hash methods
+ * and compared to the pre-defined value from either
+ * the environment variable "bootstopkeycrypt"
+ * or
+ * the config value CONFIG_AUTOBOOT_STOP_STR_CRYPT
+ *
+ * @etime: Timeout value ticks (stop when get_ticks() reachs this)
+ * @return 0 if autoboot should continue, 1 if it should stop
+ */
+static int passwd_abort_crypt(uint64_t etime)
+{
+ const char *crypt_env_str = env_get("bootstopkeycrypt");
+ char presskey[MAX_DELAY_STOP_STR];
+ u_int presskey_len = 0;
+ int abort = 0;
+ int err;
+
+ if (IS_ENABLED(CONFIG_AUTOBOOT_STOP_STR_ENABLE) && !crypt_env_str)
+ crypt_env_str = CONFIG_AUTOBOOT_STOP_STR_CRYPT;
+
+ if (!crypt_env_str)
+ return 0;
+
+ /* We expect the stop-string to be newline-terminated */
+ do {
+ if (tstc()) {
+
[PATCH v4 2/8] lib: wrap crypt API to hide errno usage
In order to prevent using the global errno, replace it with a static
version and create a wrapper function which returns the error value.
Signed-off-by: Steffen Jaeckel
Reviewed-by: Simon Glass
---
(no changes since v1)
include/crypt.h | 3 ++-
lib/crypt/alg-sha256.h | 6 --
lib/crypt/alg-sha512.h | 6 --
lib/crypt/crypt-port.h | 18 ++
lib/crypt/crypt-sha256.c | 26 --
lib/crypt/crypt-sha512.c | 26 --
lib/crypt/crypt.c| 25 ++---
test/lib/test_crypt.c| 24 ++--
8 files changed, 96 insertions(+), 38 deletions(-)
diff --git a/include/crypt.h b/include/crypt.h
index e0be2832ff..f18a1705d4 100644
--- a/include/crypt.h
+++ b/include/crypt.h
@@ -9,5 +9,6 @@
* @equal Pointer to an int where the result is stored
* '0' = unequal
* '1' = equal
+ * @return 0 on success, error code of errno else
*/
-void crypt_compare(const char *should, const char *passphrase, int *equal);
+int crypt_compare(const char *should, const char *passphrase, int *equal);
diff --git a/lib/crypt/alg-sha256.h b/lib/crypt/alg-sha256.h
index e4b29c9f31..62e7b9d5c0 100644
--- a/lib/crypt/alg-sha256.h
+++ b/lib/crypt/alg-sha256.h
@@ -1,12 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/* Copyright (C) 2020 Steffen Jaeckel */
-#ifndef USE_HOSTCC
-#include "common.h"
-#else
-#include
-#endif
-
#include "u-boot/sha256.h"
#define INCLUDE_sha256crypt 1
diff --git a/lib/crypt/alg-sha512.h b/lib/crypt/alg-sha512.h
index 93b6109fae..47e45730cc 100644
--- a/lib/crypt/alg-sha512.h
+++ b/lib/crypt/alg-sha512.h
@@ -1,12 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/* Copyright (C) 2020 Steffen Jaeckel */
-#ifndef USE_HOSTCC
-#include "common.h"
-#else
-#include
-#endif
-
#include "u-boot/sha512.h"
#define INCLUDE_sha512crypt 1
diff --git a/lib/crypt/crypt-port.h b/lib/crypt/crypt-port.h
index 680ffe9349..6b9542d75b 100644
--- a/lib/crypt/crypt-port.h
+++ b/lib/crypt/crypt-port.h
@@ -18,11 +18,13 @@ extern const unsigned char ascii64[65];
#define b64t ((const char *)ascii64)
-void crypt_sha256crypt_rn(const char *phrase, size_t phr_size,
- const char *setting, size_t ARG_UNUSED(set_size),
- uint8_t *output, size_t out_size, void *scratch,
- size_t scr_size);
-void crypt_sha512crypt_rn(const char *phrase, size_t phr_size,
- const char *setting, size_t ARG_UNUSED(set_size),
- uint8_t *output, size_t out_size, void *scratch,
- size_t scr_size);
+int crypt_sha256crypt_rn_wrapped(const char *phrase, size_t phr_size,
+const char *setting,
+size_t ARG_UNUSED(set_size), uint8_t *output,
+size_t out_size, void *scratch,
+size_t scr_size);
+int crypt_sha512crypt_rn_wrapped(const char *phrase, size_t phr_size,
+const char *setting,
+size_t ARG_UNUSED(set_size), uint8_t *output,
+size_t out_size, void *scratch,
+size_t scr_size);
diff --git a/lib/crypt/crypt-sha256.c b/lib/crypt/crypt-sha256.c
index 37127d41e1..e1c1eff060 100644
--- a/lib/crypt/crypt-sha256.c
+++ b/lib/crypt/crypt-sha256.c
@@ -1,10 +1,13 @@
+// SPDX-License-Identifier: CC0-1.0
/* One way encryption based on the SHA256-based Unix crypt implementation.
*
* Written by Ulrich Drepper in 2007 [1].
* Modified by Zack Weinberg in 2017, 2018.
* Composed by Björn Esser in 2018.
* Modified by Björn Esser in 2020.
- * Modified by Steffen Jaeckel in 2020.
+ * Modified by Steffen Jaeckel in 2021
+ * for U-Boot, instead of using the global errno to use a static one
+ * inside this file.
* To the extent possible under law, the named authors have waived all
* copyright and related or neighboring rights to this work.
*
@@ -20,7 +23,7 @@
#include "crypt-port.h"
#include "alg-sha256.h"
-#include
+#include
#include
#include
@@ -69,6 +72,25 @@ static_assert (sizeof (struct sha256_buffer) <=
ALG_SPECIFIC_SIZE,
"ALG_SPECIFIC_SIZE is too small for SHA256");
+/* Use this instead of including errno.h */
+static int errno;
+
+void crypt_sha256crypt_rn(const char *phrase, size_t phr_size,
+ const char *setting, size_t ARG_UNUSED(set_size),
+ uint8_t *output, size_t out_size, void *scratch,
+ size_t scr_size);
+
+int crypt_sha256crypt_rn_wrapped(const char *phrase, size_t phr_size,
+const char *setting, size_t set_size,
+u8 *output, size_t out_size, void *scratch,
+size_t scr_size)
+{
+ errno =
[PATCH v4 1/8] lib: add crypt subsystem
Add the basic functionality required to support the standard crypt format. The files crypt-sha256.c and crypt-sha512.c originate from libxcrypt and their formatting is therefor retained. The integration is done via a crypt_compare() function in crypt.c. ``` libxcrypt $ git describe --long --always --all tags/v4.4.17-0-g6b110bc ``` Signed-off-by: Steffen Jaeckel Reviewed-by: Simon Glass --- Changes in v4: Fix depends for unit-tests Changes in v3: Add unit-tests for autoboot Introduce `bootstopusesha256` to allow fallback to plain SHA256-based hashing Add AUTOBOOT_FLUSH_STDIN option Drop the changes to bcm963158_ram_defconfig Changes in v2: Update Kconfig way of enabling, setting hashes etc. Changes in v1: Added unit-tests of crypt_compare() Wrapped crypt functions to encapsulate errno include/crypt.h | 13 ++ lib/Kconfig | 1 + lib/Makefile | 1 + lib/crypt/Kconfig| 28 lib/crypt/Makefile | 10 ++ lib/crypt/alg-sha256.h | 17 ++ lib/crypt/alg-sha512.h | 17 ++ lib/crypt/crypt-port.h | 28 lib/crypt/crypt-sha256.c | 313 + lib/crypt/crypt-sha512.c | 328 +++ lib/crypt/crypt.c| 73 + test/Kconfig | 10 ++ test/lib/Makefile| 1 + test/lib/test_crypt.c| 44 ++ 14 files changed, 884 insertions(+) create mode 100644 include/crypt.h create mode 100644 lib/crypt/Kconfig create mode 100644 lib/crypt/Makefile create mode 100644 lib/crypt/alg-sha256.h create mode 100644 lib/crypt/alg-sha512.h create mode 100644 lib/crypt/crypt-port.h create mode 100644 lib/crypt/crypt-sha256.c create mode 100644 lib/crypt/crypt-sha512.c create mode 100644 lib/crypt/crypt.c create mode 100644 test/lib/test_crypt.c diff --git a/include/crypt.h b/include/crypt.h new file mode 100644 index 00..e0be2832ff --- /dev/null +++ b/include/crypt.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* Copyright (C) 2020 Steffen Jaeckel */ + +/** + * Compare should with the processed passphrase. + * + * @should The crypt-style string to compare against + * @passphrase The plaintext passphrase + * @equal Pointer to an int where the result is stored + * '0' = unequal + * '1' = equal + */ +void crypt_compare(const char *should, const char *passphrase, int *equal); diff --git a/lib/Kconfig b/lib/Kconfig index ad0cd52edd..ad4d75e0a4 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -297,6 +297,7 @@ config AES source lib/rsa/Kconfig source lib/crypto/Kconfig +source lib/crypt/Kconfig config TPM bool "Trusted Platform Module (TPM) Support" diff --git a/lib/Makefile b/lib/Makefile index 881034f4ae..3e613540ef 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_HASH) += hash-checksum.o obj-$(CONFIG_SHA1) += sha1.o obj-$(CONFIG_SHA256) += sha256.o obj-$(CONFIG_SHA512_ALGO) += sha512.o +obj-$(CONFIG_CRYPT_PW) += crypt/ obj-$(CONFIG_$(SPL_)ZLIB) += zlib/ obj-$(CONFIG_$(SPL_)ZSTD) += zstd/ diff --git a/lib/crypt/Kconfig b/lib/crypt/Kconfig new file mode 100644 index 00..5495ae8d4c --- /dev/null +++ b/lib/crypt/Kconfig @@ -0,0 +1,28 @@ +menuconfig CRYPT_PW + bool "Add crypt support for password-based unlock" + depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION + help + Enable support for crypt-style hashed passphrases. + This will then be used as the mechanism of choice to + verify whether the entered password to unlock the + console is correct or not. + +if CRYPT_PW + +config CRYPT_PW_SHA256 + bool "Provide sha256crypt" + select SHA256 + select SHA256_ALGO + help + Enables support for the sha256crypt password-hashing algorithm. + The prefix is "$5$". + +config CRYPT_PW_SHA512 + bool "Provide sha512crypt" + select SHA512 + select SHA512_ALGO + help + Enables support for the sha512crypt password-hashing algorithm. + The prefix is "$6$". + +endif diff --git a/lib/crypt/Makefile b/lib/crypt/Makefile new file mode 100644 index 00..290231064c --- /dev/null +++ b/lib/crypt/Makefile @@ -0,0 +1,10 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (c) 2013, Google Inc. +# +# (C) Copyright 2000-2007 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. + +obj-$(CONFIG_CRYPT_PW) += crypt.o +obj-$(CONFIG_CRYPT_PW_SHA256) += crypt-sha256.o +obj-$(CONFIG_CRYPT_PW_SHA512) += crypt-sha512.o diff --git a/lib/crypt/alg-sha256.h b/lib/crypt/alg-sha256.h new file mode 100644 index 00..e4b29c9f31 --- /dev/null +++ b/lib/crypt/alg-sha256.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* Copyright (C) 2020 Steffen Jaeckel */ + +#ifndef USE_HOSTCC +#include "common.h" +#else +#include +#endif + +#include "u-boot/sha256.h" + +#define INCLUDE_sha256crypt 1 + +#define SHA256_CTX sha256_context +#defi
[PATCH v4 0/8] common: Introduce crypt-style password support
This patchset introduces support for crypt-style passwords to unlock the console in autoboot mode. The implementation of crypt-sha256 and crypt-sha512 originate from libxcrypt at https://github.com/besser82/libxcrypt.git Version v4.4.17 Git commit hash 6b110bc I didn't re-format those two files to make diffing to the original versions from libxcrypt easier, which leads to a huge load of checkpatch.pl warnings&errors. Please advise on whether they should be re-formatted or can be kept as is. The remaining warnings from checkpatch.pl are intentional resp. open for discussion. A sandbox defconfig with password entry has been added. I'm not sure whether this should be kept or not, it's just there as an example. Cheers, Steffen Changes in v4: Fix depends for unit-tests Take review comments into account Add another test with `bootstopusesha256` unset Changes in v3: Add unit-tests for autoboot Introduce `bootstopusesha256` to allow fallback to plain SHA256-based hashing Add AUTOBOOT_FLUSH_STDIN option Drop the changes to bcm963158_ram_defconfig Changes in v2: Update Kconfig way of enabling, setting hashes etc. Changes in v1: Added unit-tests of crypt_compare() Wrapped crypt functions to encapsulate errno Steffen Jaeckel (8): lib: add crypt subsystem lib: wrap crypt API to hide errno usage common: integrate crypt-based passwords common: Rename macro appropriately common: allow disabling of timeout for password entry common: add AUTOBOOT_FLUSH_STDIN option common: add support to fallback to plain SHA256 test: add first autoboot unit tests common/Kconfig.boot | 65 ++- common/autoboot.c | 136 -- common/console.c| 5 + configs/sandbox_defconfig | 13 +- include/console.h | 17 ++ include/crypt.h | 14 ++ include/test/common.h | 15 ++ include/test/suites.h | 1 + lib/Kconfig | 1 + lib/Makefile| 1 + lib/crypt/Kconfig | 28 +++ lib/crypt/Makefile | 10 ++ lib/crypt/alg-sha256.h | 11 ++ lib/crypt/alg-sha512.h | 11 ++ lib/crypt/crypt-port.h | 30 lib/crypt/crypt-sha256.c| 335 ++ lib/crypt/crypt-sha512.c| 350 lib/crypt/crypt.c | 76 test/Kconfig| 10 ++ test/Makefile | 1 + test/cmd_ut.c | 1 + test/common/Makefile| 3 + test/common/cmd_ut_common.c | 22 +++ test/common/test_autoboot.c | 90 ++ test/lib/Makefile | 1 + test/lib/test_crypt.c | 64 +++ 26 files changed, 1288 insertions(+), 23 deletions(-) create mode 100644 include/crypt.h create mode 100644 include/test/common.h create mode 100644 lib/crypt/Kconfig create mode 100644 lib/crypt/Makefile create mode 100644 lib/crypt/alg-sha256.h create mode 100644 lib/crypt/alg-sha512.h create mode 100644 lib/crypt/crypt-port.h create mode 100644 lib/crypt/crypt-sha256.c create mode 100644 lib/crypt/crypt-sha512.c create mode 100644 lib/crypt/crypt.c create mode 100644 test/common/Makefile create mode 100644 test/common/cmd_ut_common.c create mode 100644 test/common/test_autoboot.c create mode 100644 test/lib/test_crypt.c -- 2.32.0
Re: [PATCH v2 1/2] mmc: Check for device with a seq number equal to num before checking against index
Hi Aswath,
Thanks for the quick response.
On Wed, Jul 7, 2021 at 1:55 AM Aswath Govindraju wrote:
>
> Hi Ricardo,
>
> On 07/07/21 4:39 am, Ricardo Salveti wrote:
> > Hi Aswath,
> >
> > On Thu, Mar 25, 2021 at 4:19 AM Aswath Govindraju
> > wrote:
> >>
> >> First check if there is an alias for the device tree node defined with the
> >> given num before checking against device index.
> >>
> >> Signed-off-by: Aswath Govindraju
> >> Reviewed-by: Lokesh Vutla
> >> Reviewed-by: Jaehoon Chung
> >> ---
> >> drivers/mmc/mmc.c | 8 +---
> >> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >> index b4c8e7f293bd..1e83007286b2 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -3052,9 +3052,11 @@ int mmc_init_device(int num)
> >> struct mmc *m;
> >> int ret;
> >>
> >> - ret = uclass_get_device(UCLASS_MMC, num, &dev);
> >> - if (ret)
> >> - return ret;
> >> + if (uclass_get_device_by_seq(UCLASS_MMC, num, &dev)) {
> >> + ret = uclass_get_device(UCLASS_MMC, num, &dev);
> >> + if (ret)
> >> + return ret;
> >> + }
> >
> > uclass_get_device_by_seq returns 0 if OK and -ve on error, so I
> > believe this check is incorrect and we never end up calling
> > uclass_get_device on the working path.
>
> Yes, as you mentioned uclass_get_device_by_seq() returns 0 if OK and -ve
> on error is correct. However, the intention of this check here, is to
> only call uclass_get_device() when uclass_get_device_by_seq() returns an
> error.
>
> uclass_get_device_by_seq() returns the device only if it is able find a
> active device with matching sequence number "num" or will try to find a
> device that is requesting this number. As this function also returns the
> device we need not call uclass_get_device() again. Only on failure for
> find a device with matching sequence number do we call uclass_get_device().
>
> So, I believe the above mentioned check is correct.
>
> > While bisecting to try to debug why my zynqmp-based device is unable
> > to boot u-boot, I stopped at this patch (merged as part of
> > v2021.07-rc1).
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 1e83007286b..56556353f8e 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -3052,11 +3052,13 @@ int mmc_init_device(int num)
> > struct mmc *m;
> > int ret;
> >
> > - if (uclass_get_device_by_seq(UCLASS_MMC, num, &dev)) {
> > - ret = uclass_get_device(UCLASS_MMC, num, &dev);
> > - if (ret)
> > - return ret;
> > - }
> > + ret = uclass_get_device_by_seq(UCLASS_MMC, num, &dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = uclass_get_device(UCLASS_MMC, num, &dev);
> > + if (ret)
> > + return ret;
> >
> > m = mmc_get_mmc_dev(dev);
> > if (!m)
> >
>
> In the above method, the device is being fetched twice and I believe
> that this method is incorrect.
You're right, I had to read more about how seq is related with aliases
to understand the difference here.
> > This is enough for it to work correctly again, but I just wanted to
> > reply back here first before submitting as I'm surprised nobody
> > reported this issue before.
>
> If making this change got it work correctly again. I believe there might
> have been a error in assigning aliases for mmc devices in the device
> tree. As only after this patch are aliases being read for mmc class of
> devices from the device tree.
Was finally able to understand what happened, and it is indeed related
to how the aliases were used by this board.
At spl_mmc_find_device the function spl_mmc_get_device_index was
called with BOOT_DEVICE_MMC2 (sdcard on my board), following with
mmc_init_device (mmc_dev 1). This caused uclass_get_device_by_seq to
be called with num 1 (alias 1), which ended up loading the eMMC device
instead of sdcard, causing the boot failure.
Looking at my dts, this now makes sense as mmc0 was an alias to sdcard
while mmc1 to emmc. Inverting the alias node was enough to get my
board to boot again.
diff --git a/uz3eg-iocc/system-som.dtsi b/system-som.dtsi
index 192e343..ec2b8a2 100644
--- a/system-som.dtsi
+++ b/system-som.dtsi
@@ -21,8 +21,8 @@
aliases {
gpio0 = &gpio;
- mmc0 = &sdhci1;
- mmc1 = &sdhci0;
+ mmc1 = &sdhci1;
+ mmc0 = &sdhci0;
rtc0 = &rtc;
serial0 = &uart0;
serial1 = &uart1;
Thanks,
--
Ricardo Salveti
Re: [PATCH v5 01/13] ata: ahci-pci: Use scsi_ops to initialize ops
Hi Tom, 2021年7月7日(水) 7:50 Tom Rini : > > On Fri, Jun 04, 2021 at 06:43:23PM +0900, Masami Hiramatsu wrote: > > > Without this fix, scsi-scan will cause a synchronous abort > > when accessing ops->scan. > > > > Signed-off-by: Masami Hiramatsu > > Reviewed-by: Simon Glass > > For the entire series, applied to u-boot/master, thanks! Thank you so much! I have some updates, so I'll send it. Regards, -- Masami Hiramatsu
Re: [PATCH 3/5] efi_loader: add boot variable measurement
Hi Kojima-san,
> +{
[...]
> + u16 *boot_order;
> + u16 var_name[] = L"BootOrder";
> + u16 boot_name[] = L"Boot";
> + u16 hexmap[] = L"0123456789ABCDEF";
> + u8 *bootvar;
> + efi_uintn_t var_data_size;
> + u32 count, i;
> + efi_status_t ret;
> +
> + boot_order = efi_get_var(var_name, &efi_global_variable_guid,
> + &var_data_size);
> + if (!boot_order) {
> + log_info("BootOrder not defined\n");
> + ret = EFI_NOT_FOUND;
> + goto error;
> + }
> +
> + ret = tcg2_measure_variable(dev, 1, EV_EFI_VARIABLE_BOOT2, var_name,
> + &efi_global_variable_guid, var_data_size,
> + (u8 *)boot_order);
> + if (ret != EFI_SUCCESS)
> + goto error;
> +
> + count = var_data_size / sizeof(*boot_order);
> + for (i = 0; i < count; i++) {
> + boot_name[4] = hexmap[(boot_order[i] & 0xf000) >> 12];
> + boot_name[5] = hexmap[(boot_order[i] & 0x0f00) >> 8];
> + boot_name[6] = hexmap[(boot_order[i] & 0x00f0) >> 4];
> + boot_name[7] = hexmap[(boot_order[i] & 0x000f)];
Can you use efi_create_indexed_name() instead?
[...]
> + for (pcr_index = 0; pcr_index <= 7; pcr_index++) {
> + ret = tcg2_measure_event(dev, pcr_index, EV_SEPARATOR,
> + sizeof(event), (u8 *)&event);
I assume adding a separator event on all these PCRs is described on the
standard?
> + if (ret != EFI_SUCCESS)
> + goto out;
> + }
> +
> + tcg2_efi_app_invoked = true;
> +out:
> + return ret;
> +}
> +
> +/**
> + * efi_tcg2_measure_efi_app_exit() - measure efi app exit
> + *
> + * Return: status code
> + */
> +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void)
> +{
> + efi_status_t ret;
> + struct udevice *dev;
> +
> + ret = platform_get_tpm2_device(&dev);
> + if (ret != EFI_SUCCESS)
> + return ret;
> +
> + ret = tcg2_measure_event(dev, 4, EV_EFI_ACTION,
> + strlen(EFI_RETURNING_FROM_EFI_APPLICATION),
Do we need a NUL terminator on this string or not?
Regards
/Ilias
Re: [PATCH 2/5] efi_loader: add secure boot variable measurement
On Wed, Jul 07, 2021 at 11:49:33AM -0600, Simon Glass wrote: > Hi Ilias, > > On Wed, 7 Jul 2021 at 11:40, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Wed, Jul 07, 2021 at 11:37:01AM -0600, Simon Glass wrote: > > > Hi Masahisa, > > > > > > On Wed, 7 Jul 2021 at 07:36, Masahisa Kojima > > > wrote: > > > > > > > > TCG PC Client PFP spec requires to measure the secure > > > > boot policy before validating the UEFI image. > > > > This commit adds the secure boot variable measurement > > > > of "SecureBoot", "PK", "KEK", "db" and "dbx". > > > > > > > > Note that this implementation assumes that secure boot > > > > variables are pre-configured and not be set/updated in runtime. > > > > > > > > Signed-off-by: Masahisa Kojima > > > > --- > > > > include/efi_tcg2.h| 20 ++ > > > > lib/efi_loader/efi_tcg2.c | 135 ++ > > > > 2 files changed, 155 insertions(+) > > > > > > Where are the tests for this code, please? > > > > As we discussed in the past, the EFI TCG code can't be tested with the > > asndbox as-is. I'll have a look on your sandbox patches in case we can now > > use those, but in any case, I've sent a TPM mmio based driver. Even if the > > sandbox is still not enough we can add tests once the mmio TPM driver gets > > merged > > Can you add features to the sandbox driver? I just sent a series that > added nvdata, for example. Yea I've seen that, I was going to have a look. I'll try but my schedule is pretty tight atm. Thanks /Ilias > > Regards, > Simon
Re: [PATCH 2/5] efi_loader: add secure boot variable measurement
Hi Ilias, On Wed, 7 Jul 2021 at 11:40, Ilias Apalodimas wrote: > > Hi Simon, > > On Wed, Jul 07, 2021 at 11:37:01AM -0600, Simon Glass wrote: > > Hi Masahisa, > > > > On Wed, 7 Jul 2021 at 07:36, Masahisa Kojima > > wrote: > > > > > > TCG PC Client PFP spec requires to measure the secure > > > boot policy before validating the UEFI image. > > > This commit adds the secure boot variable measurement > > > of "SecureBoot", "PK", "KEK", "db" and "dbx". > > > > > > Note that this implementation assumes that secure boot > > > variables are pre-configured and not be set/updated in runtime. > > > > > > Signed-off-by: Masahisa Kojima > > > --- > > > include/efi_tcg2.h| 20 ++ > > > lib/efi_loader/efi_tcg2.c | 135 ++ > > > 2 files changed, 155 insertions(+) > > > > Where are the tests for this code, please? > > As we discussed in the past, the EFI TCG code can't be tested with the > asndbox as-is. I'll have a look on your sandbox patches in case we can now > use those, but in any case, I've sent a TPM mmio based driver. Even if the > sandbox is still not enough we can add tests once the mmio TPM driver gets > merged Can you add features to the sandbox driver? I just sent a series that added nvdata, for example. Regards, Simon
Re: [PATCH 2/5] efi_loader: add secure boot variable measurement
Hi Simon, On Wed, Jul 07, 2021 at 11:37:01AM -0600, Simon Glass wrote: > Hi Masahisa, > > On Wed, 7 Jul 2021 at 07:36, Masahisa Kojima > wrote: > > > > TCG PC Client PFP spec requires to measure the secure > > boot policy before validating the UEFI image. > > This commit adds the secure boot variable measurement > > of "SecureBoot", "PK", "KEK", "db" and "dbx". > > > > Note that this implementation assumes that secure boot > > variables are pre-configured and not be set/updated in runtime. > > > > Signed-off-by: Masahisa Kojima > > --- > > include/efi_tcg2.h| 20 ++ > > lib/efi_loader/efi_tcg2.c | 135 ++ > > 2 files changed, 155 insertions(+) > > Where are the tests for this code, please? As we discussed in the past, the EFI TCG code can't be tested with the asndbox as-is. I'll have a look on your sandbox patches in case we can now use those, but in any case, I've sent a TPM mmio based driver. Even if the sandbox is still not enough we can add tests once the mmio TPM driver gets merged Cheers /Ilias > > Regards, > Simon
Re: QEMU NUMA and U-Boot
On 7/7/21 5:15 PM, François Ozog wrote:
top posting what now works for me:
- changed calculation of memory size to loop through different memory nodes
- added numa_node to banks
- filter out banks that do not match the target mixup node (do not want
to change ABI to add node information)
That's not satisfying overall but at least my code works with NUMA on Qemu.
Do we expect real hardware with NUMA to be using U-Boot?
If you have real ARM hardware in NUMA configuration, can the boot CPU
access memory of dormant CPUs when U-Boot is entered?
Best regards
Heinrich
*diff --git a/Kconfig b/Kconfig*
*index f8c1a77bed..4d3ab8cb49 100644*
*--- a/Kconfig*
*+++ b/Kconfig*
@@ -192,7 +192,9 @@config NR_DRAM_BANKS
default 1 if ARCH_SUNXI || ARCH_OWL
default 4
help
- This defines the number of DRAM banks.
+This defines the number of DRAM banks. For qemu with NUMA, you
+may want to set this value to * .
+for instance, for a 2 slot with 4 memdevs set NR_DRAM_BANKS to 8.
config SYS_BOOT_GET_CMDLINE
bool "Enable kernel command line setup"
*diff --git a/arch/arm/lib/bootm-fdt.c b/arch/arm/lib/bootm-fdt.c*
*index 29020bd1c6..2b28ab8108 100644*
*--- a/arch/arm/lib/bootm-fdt.c*
*+++ b/arch/arm/lib/bootm-fdt.c*
@@ -42,12 +42,17 @@int arch_fixup_fdt(void *blob)
u64 size[CONFIG_NR_DRAM_BANKS];
for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+unsigned char node = bd->bi_dram[bank].numa_node;
start[bank] = bd->bi_dram[bank].start;
size[bank] = bd->bi_dram[bank].size;
#ifdef CONFIG_ARMV7_NONSEC
ret = armv7_apply_memory_carveout(&start[bank], &size[bank]);
if (ret)
return ret;
+#endif
+#ifdef CONFIG_OF_LIBFDT
+/* add node info for the fdt_fixup_memory below */
+start[bank] = (((phys_addr_t)node) << 56) | bd->bi_dram[bank].start;
#endif
}
*diff --git a/common/fdt_support.c b/common/fdt_support.c*
*index a9a32df1e7..3bca2ba888 100644*
*--- a/common/fdt_support.c*
*+++ b/common/fdt_support.c*
@@ -415,16 +415,29 @@static int fdt_pack_reg(const void *fdt, void *buf,
u64 *address, u64 *size,
return p - (char *)buf;
}
+static inline uint32_t fdt32_ld(const fdt32_t *p)
+{
+const uint8_t *bp = (const uint8_t *)p;
+
+return ((uint32_t)bp[0] << 24)
+ | ((uint32_t)bp[1] << 16)
+ | ((uint32_t)bp[2] << 8)
+ | bp[3];
+}
#if CONFIG_NR_DRAM_BANKS > 4
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
#define MEMORY_BANKS_MAX 4
#endif
+/* NUMA has yet to be properly handled
+ * This code appends memory to the first memory node that matches the
NUMA node.
+ */
int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
{
int err, nodeoffset;
int len, i;
u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
+unsigned int numa_node;
if (banks > MEMORY_BANKS_MAX) {
printf("%s: num banks %d exceeds hardcoded limit %d."
@@ -444,6 +457,12 @@int fdt_fixup_memory_banks(void *blob, u64 start[],
u64 size[], int banks)
if (nodeoffset < 0)
return nodeoffset;
+const __be32* numa_node_prop = fdt_getprop(blob, nodeoffset,
"numa-node-id", &len);
+if (numa_node_prop != NULL && len == sizeof(__be32)) {
+numa_node = fdt32_ld(numa_node_prop);
+}
+else numa_node = 0;
+
err = fdt_setprop(blob, nodeoffset, "device_type", "memory",
sizeof("memory"));
if (err < 0) {
@@ -453,8 +472,27 @@int fdt_fixup_memory_banks(void *blob, u64 start[],
u64 size[], int banks)
}
for (i = 0; i < banks; i++) {
- if (start[i] == 0 && size[i] == 0)
+/* clear node information */
+unsigned int node;
+recheck:
+if (start[i]== 0 && size[i] == 0)
break;
+node = (start[i] >> 56) & 0xFF;
+start[i] = start[i] & 0x00FF;
+/* for the moment, just ignore the banks that are not in
+* memory NUMA node */
+if (node != numa_node) {
+/* remove the bank from the list */
+int j;
+for (j=i; j < banks-1; j++) {
+start[j] = start[j+1];
+size[j] = size[j+1];
+}
+start[j]=0;
+size[j]=0;
+banks--;
+goto recheck;
+}
}
banks = i;
@@ -470,6 +508,7 @@int fdt_fixup_memory_banks(void *blob, u64 start[],
u64 size[], int banks)
"reg", fdt_strerror(err));
return err;
}
+
return 0;
}
*diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig*
*index f6e586627a..0fdc22d71d 100644*
*--- a/configs/qemu_arm64_defconfig*
*+++ b/configs/qemu_arm64_defconfig*
@@ -1,7 +1,7 @@
CONFIG_ARM=y
CONFIG_POSITION_INDEPENDENT=y
CONFIG_ARCH_QEMU=y
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=32
CONFIG_ENV_SIZE=0x4
CONFIG_ENV_SECT_SIZE=0x4
CONFIG_AHCI=y
*diff --git a/include/asm-generic/u-boot.h b/include/asm-generic/u-boot.h*
*index 637de0c455..3cf45124ec 100644*
*--- a/include/asm-generic/u-boot.h*
*+++ b/include/asm-generic/u-boot.h*
@@ -71,6 +71,8 @@struct bd_info {
struct {/* RAM configuration */
phys_addr_t start;
phys_size_t size;
+unsigned numa_node;
+unsigned pad; /* just to make sure we do not cause alignment */
} bi_dram[CONFIG_NR_DRAM_BANKS];
};
*diff --git a/lib/fdtdec.c b/lib/fdtdec.c*
*index 4b097fb588..b1934edc8
Re: [PATCH 1/1] sandbox: don't set SA_NODEFER in signal handler
Hi Heinrich, On Mon, 5 Jul 2021 at 11:43, Heinrich Schuchardt wrote: > > The sandbox can handle signals. Due to a damaged global data pointer > additional exceptions in the signal handler may occur leading to an endless > loop. In this case leave the handling of the secondary exception to the > operating system. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/os.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I'm OK with this since it doesn't actually matter, now that the signal-catching behaviour is optional. But as I understand it, it will mean that the second exception is reported, but not the first? In other words, any core dump will be 'incorrect' in that it is not suitable for postmortem debugging. > > diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c > index 0d21827e1b..9a73ae3b18 100644 > --- a/arch/sandbox/cpu/os.c > +++ b/arch/sandbox/cpu/os.c > @@ -226,7 +226,7 @@ int os_setup_signal_handlers(void) > > act.sa_sigaction = os_signal_handler; > sigemptyset(&act.sa_mask); > - act.sa_flags = SA_SIGINFO | SA_NODEFER; > + act.sa_flags = SA_SIGINFO; > if (sigaction(SIGILL, &act, NULL) || > sigaction(SIGBUS, &act, NULL) || > sigaction(SIGSEGV, &act, NULL)) > -- > 2.30.2 > Regards, Simon
Re: [PATCH 1/8] imx8mm: Fix USB reg addresses for i.MX8MM
Hi,
On Tue, 6 Jul 2021 at 15:17, Marek Vasut wrote:
>
> On 7/6/21 6:11 PM, Tim Harvey wrote:
> > On Sun, Jul 4, 2021 at 12:25 PM Marek Vasut wrote:
> >>
> >> On 7/4/21 5:35 PM, Fabio Estevam wrote:
> >>> Hi Marek,
> >>
> >> Hi,
> >>
> >>> On Sat, Jul 3, 2021 at 10:04 PM Marek Vasut wrote:
> >>>
> > Retrieving the USB base addresses from DT would be preferred, yes, but
> > the current code does not do that.
>
> I implemented exactly that in mx6_parse_dt_addrs() , see:
> 4dcfa3bcbcb ("usb: ehci-mx6: Parse USB PHY and MISC offsets from DT")
> >>>
> >>> We are talking about USB_BASE_ADDR, right?
> >>
> >> All of the addresses used by the driver, I am trying hard to get rid of
> >> all that hard-coding in the driver. They should be parsed out of DT.
> >>
> >
> > Marek,
> >
> > I agree with trying to get rid of all the hard-coding but not all of
> > us are using SPL_DM_USB. I'm not sure how to best tell who is not
> > using DM in the SPL.
>
> You should be able to use PLATDATA in SPL.
>
> The current situation in the driver is total chaos, that must be fixed.
> So, I would say in SPL -> PLATDATA , U-Boot -> DM/DT .
>
> > I know I ran into issues as I'm supporting a
> > family of boards with the same U-Boot and could not find a way to
> > switch dt's early in the SPL after I've detected via EEPROM what board
> > I have.
>
> Right, the platdata should help here. Then you don't need DT.
I suggest using of-platdata, so you can still use DT but it gets
compiled into the C code.
Regards,
Simon
Re: [PATCH v2] dm: core: fix no null pointer detection in ofnode_get_addr_size_index()
Hi Chenguanqiao, On Mon, 5 Jul 2021 at 21:21, chenguanqiao wrote: > > From: Chen Guanqiao > > Fixed a defect of a null pointer being discovered by Coverity Scan: >CID 331544: Null pointer dereferences (REVERSE_INULL) >Null-checking "size" suggests that it may be null, but it has already been >dereferenced on all paths leading to the check. > > Signed-off-by: Chen Guanqiao > --- > drivers/core/ofnode.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) This is a v2 but does not have a change log. Regards, Simon
Re: [PATCH 2/5] efi_loader: add secure boot variable measurement
Hi Masahisa, On Wed, 7 Jul 2021 at 07:36, Masahisa Kojima wrote: > > TCG PC Client PFP spec requires to measure the secure > boot policy before validating the UEFI image. > This commit adds the secure boot variable measurement > of "SecureBoot", "PK", "KEK", "db" and "dbx". > > Note that this implementation assumes that secure boot > variables are pre-configured and not be set/updated in runtime. > > Signed-off-by: Masahisa Kojima > --- > include/efi_tcg2.h| 20 ++ > lib/efi_loader/efi_tcg2.c | 135 ++ > 2 files changed, 155 insertions(+) Where are the tests for this code, please? Regards, Simon
Re: [PATCH v3 8/8] test: add first autoboot unit tests
Hi Steffen,
On Wed, 7 Jul 2021 at 04:39, Steffen Jaeckel
wrote:
>
> Hi Simon,
>
> thanks again for the review!
>
> On 6/26/21 8:32 PM, Simon Glass wrote:
> > On Mon, 21 Jun 2021 at 14:25, Steffen Jaeckel
> > wrote:
> >>
> >> This adds tests for the crypt-based and plain SHA256-based password hashing
> >> algorithms in the autoboot flow.
> >>
> >> Signed-off-by: Steffen Jaeckel
> >> ---
> >>
> >> (no changes since v1)
> >>
> >> common/Kconfig.boot | 2 +-
> >> common/console.c| 5 +++
> >> configs/sandbox_defconfig | 11 +
> >> include/console.h | 17 +++
> >> include/test/common.h | 15 +++
> >> include/test/suites.h | 1 +
> >> test/Makefile | 1 +
> >> test/cmd_ut.c | 1 +
> >> test/common/Makefile| 3 ++
> >> test/common/cmd_ut_common.c | 22 +
> >> test/common/test_autoboot.c | 90 +
> >> 11 files changed, 167 insertions(+), 1 deletion(-)
> >> create mode 100644 include/test/common.h
> >> create mode 100644 test/common/Makefile
> >> create mode 100644 test/common/cmd_ut_common.c
> >> create mode 100644 test/common/test_autoboot.c
> >
> > Reviewed-by: Simon Glass
> >
> > but please make sure patman does not give you checkpatch warnings. I
> > see one, I think.
>
> I see two potential candidates
>
> > test/common/test_autoboot.c:27: warning: braces {} are not necessary for
> > single statement blocks
> > test/common/test_autoboot.c:62: warning: line length of 106 exceeds 100
> > columns
>
> Which one are you referring to?
The first one, I think.
>
> I've fixed the braces one.
>
> The line length one if changed leads to another warning "warning: quoted
> string split across lines".
Yes we prefer to have long lines than split strings.
Regards,
Simon
Re: [PATCH] x86: Drop _X86EMU_env definition when CONFIG_BIOSEMU is used
Hi Bin, On Wed, 7 Jul 2021 at 01:36, Bin Meng wrote: > > With x86 we can execute an option ROM either natively or using the > x86 emulator (if enabled with CONFIG_BIOSEMU). Both of these share > the _X86EMU_env variable, with the native code using it to hold > register state during interrupt processing. > > At present, in 32-bit U-Boot, the variable is declared twice, once > in common code and once in code only compiled with CONFIG_BIOSEMU. > > With GCC 11 this causes a 'multiple definitions' error on boards > with CONFIG_BIOSEMU. > > Drop the emulator definition when CONFIG_BIOSEMU is used. > > Signed-off-by: Bin Meng > --- > > arch/x86/lib/bios.c | 2 ++ > 1 file changed, 2 insertions(+) This seems a bit hacky. Should we define a new Kconfig that both use, then put this declaration in a common file? > > diff --git a/arch/x86/lib/bios.c b/arch/x86/lib/bios.c > index fbdc3b04e3..98cc05de2e 100644 > --- a/arch/x86/lib/bios.c > +++ b/arch/x86/lib/bios.c > @@ -23,7 +23,9 @@ > static int (*int_handler[256])(void); > > /* to have a common register file for interrupt handlers */ > +#ifndef CONFIG_BIOSEMU > X86EMU_sysEnv _X86EMU_env; > +#endif > > asmlinkage void (*realmode_call)(u32 addr, u32 eax, u32 ebx, u32 ecx, u32 > edx, > u32 esi, u32 edi); > -- > 2.25.1 > Regards, Simon
Re: [PATCHv4] Azure/GitLab: Move to gcc-11.1.0 and LLVM-11
On Fri, Jul 02, 2021 at 10:41:58AM -0400, Tom Rini wrote: > - Move to gcc-11.1.0 builds from kernel.org for supported platforms and > LLVM-11 for those tests. > - As Heinrich has noted, the RISC-V platform specification has a profile > OS-A for running rich operating systems like Linux and BSD. This profile > requires 64bit and UEFI conforming to the EBBR. Only the 'embedded' > profile may use 32bit. Given this, drop grub for 32bit RISC-V as it no > longer compiles with gcc-11.1 and upstream is unlikely to fix it: > https://www.mail-archive.com/grub-devel@gnu.org/msg30736.html > - Update to grub-2.06 release to address other issues of building with > gcc-11.1. > - Update to newer Xtensa (gcc-9.2.0) and ARC (gcc-10.2) toolchains > > Cc: Heinrich Schuchardt > Cc: Bin Meng > Cc: Simon Glass > Cc: Rick Chen > Signed-off-by: Tom Rini > Reviewed-by: Bin Meng Removed installing riscv32 toolchain as well, per feedback and applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 6/7] bootstage: Eliminate when not enabled
On Mon, May 03, 2021 at 04:48:58PM -0400, Tom Rini wrote: > When we do not have bootstage enabled, rather than include an empty > dummy function, we just don't reference it. This saves us space in some > tight builds. This also shows a few cases where show_boot_progress was > incorrectly guarded before. > > Cc: Simon Glass > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 5/7] Makefile: Disable gcc-10.0 warnings
On Mon, May 03, 2021 at 04:48:57PM -0400, Tom Rini wrote: > Based on 5c45de21a2223, 44720996e2d79 and 5a76021c2eff7 in Linux > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 4/7] pinctrl: mscc: Fix multiple definition error
On Mon, May 03, 2021 at 04:48:56PM -0400, Tom Rini wrote: > With gcc-11 we get a multiple errors here as the declarations for > mscc_pinctrl_ops and mscc_gpio_ops are missing an extern. > > CC: Gregory CLEMENT > Cc: Lars Povlsen > Cc: Horatiu Vultur > Signed-off-by: Tom Rini > Reviewed-by: Horatiu Vultur > Reviewed-by: Daniel Schwierzeck Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 3/7] eb_cpu5282: Declare diplay_width / display_height as externs
On Mon, May 03, 2021 at 04:48:55PM -0400, Tom Rini wrote: > The board code here references the display_width / display_height > variables set in the video driver, declare these as externs as gcc-11 > will notice and lead to a multiple definition error. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 2/7] freescale: Drop unnecessary cpld_data_t non-typedef
On Mon, May 03, 2021 at 04:48:54PM -0400, Tom Rini wrote: > In some board cpld.h files the definition of the cpld_data struct > not-quite makes a typedef for cpld_data_t. This problem is caught with > gcc-11 as a multiple definition error. As there are no users of this > non-typedef, fix this by not declaring it one to begin with. > > Cc: Priyanka Jain > Cc: Shengzhou Liu > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 1/7] ARM: mvebu: a38x: Correct mismatched bound warnings
On Mon, May 03, 2021 at 04:48:53PM -0400, Tom Rini wrote:
> With gcc-11 we see:
> drivers/ddr/marvell/a38x/ddr3_debug.c:672:47: error: argument 2 of type
> 'u32[5]' {aka 'unsigned int[5]'} with mismatched bound
> [-Werror=array-parameter=]
> 672 | int ddr3_tip_read_adll_value(u32 dev_num, u32
> pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
> |
> ^~~
> In file included from drivers/ddr/marvell/a38x/ddr3_training_ip_engine.h:10,
> from drivers/ddr/marvell/a38x/ddr3_init.h:17,
> from drivers/ddr/marvell/a38x/ddr3_debug.c:6:
> drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h:116:47: note: previously
> declared as 'u32[]' {aka 'unsigned int[]'}
>
> And similar warnings. Correct these by updating the prototype. Remove
> the prototype for ddr3_tip_read_pup_value as it is unused.
>
> Signed-off-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PULL] u-boot-riscv/master
On Wed, Jul 07, 2021 at 11:21:13PM +0800, Leo Liang wrote: > Hi Tom, > > This is a follow up PR for OpenPiton's dts. > > Thanks for the catch. > > The following changes since commit 5617efd2c882562b716a61bc0dc0edda46b045df: > > Merge branch '2021-07-06-platform-updates' (2021-07-06 18:10:10 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to c9135d5a7af2df0e273e0f7e2f6c8132b34aba82: > > riscv: dts: add OpenPiton RISC-V board dts support (2021-07-07 20:34:02 > +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/8100 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] x86: Drop _X86EMU_env definition when CONFIG_BIOSEMU is used
On Wed, Jul 07, 2021 at 03:36:26PM +0800, Bin Meng wrote: > With x86 we can execute an option ROM either natively or using the > x86 emulator (if enabled with CONFIG_BIOSEMU). Both of these share > the _X86EMU_env variable, with the native code using it to hold > register state during interrupt processing. > > At present, in 32-bit U-Boot, the variable is declared twice, once > in common code and once in code only compiled with CONFIG_BIOSEMU. > > With GCC 11 this causes a 'multiple definitions' error on boards > with CONFIG_BIOSEMU. > > Drop the emulator definition when CONFIG_BIOSEMU is used. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
