[PATCH] bootm: fix wrong conditions about images overlap
It doesn't need to consider start byte address.
If ramdisk size is 0x80 and start address is 0x270, then it's
used until 0x02ef, not 0x02f0. But it's detected to overlapt RD
image, when kernel start address is 0x02f0.
Because it's doing wrong calculation about rd_len.
This patch fixed wrong calculation address position when check
condition.
In addition, it needs to check one more condition about overlapping
entire area.
Fixes: commit fbde7589ce30 ("common: bootm: add checks to verify if ramdisk /
fdtimage overlaps OS image")
Signed-off-by: Jaehoon Chung
---
common/bootm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index b3377490b3ef..167eea4a1e9f 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -256,9 +256,11 @@ int bootm_find_images(int flag, int argc, char *const
argv[], ulong start,
/* check if ramdisk overlaps OS image */
if (images.rd_start && (((ulong)images.rd_start >= start &&
-(ulong)images.rd_start <= start + size) ||
- ((ulong)images.rd_end >= start &&
-(ulong)images.rd_end <= start + size))) {
+(ulong)images.rd_start < start + size) ||
+ ((ulong)images.rd_end > start &&
+(ulong)images.rd_end <= start + size) ||
+ ((ulong)images.rd_start < start &&
+(ulong)images.rd_end >= start + size))) {
printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
start, start + size);
return 1;
--
2.28.0
RE: [PATCH] lib: zlib: Use post-increment only in inffast.c
> -Original Message- > From: Tom Rini > Sent: Friday, October 16, 2020 8:37 PM > To: Ley Foon Tan > Cc: Tan, Ley Foon ; ZY - u-boot b...@lists.denx.de>; See, Chin Liang > Subject: Re: [PATCH] lib: zlib: Use post-increment only in inffast.c > > On Fri, Oct 16, 2020 at 04:40:00AM +0800, Ley Foon Tan wrote: > > On Fri, Jul 17, 2020 at 9:29 PM Tom Rini wrote: > > > > > > On Wed, Jun 24, 2020 at 04:34:03PM +0800, Ley Foon Tan wrote: > > > > > > > From: Chin Liang See > > > > > > > > This fixes CVE-2016-9841. Changes integrated from [1], with > > > > changes make for Uboot code base. > > > > > > > > An old inffast.c optimization turns out to not be optimal anymore > > > > with modern compilers, and furthermore was not compliant with the > > > > C standard, for which decrementing a pointer before its allocated > > > > memory is undefined. Per the recommendation of a security audit of > > > > the zlib code by Trail of Bits and TrustInSoft, in support of the > > > > Mozilla Foundation, this "optimization" was removed, in order to > > > > avoid the possibility of undefined behavior. > > > > > > > > [1]: > > > > > https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3 > > > > 618fc380cecb > > > > > > > > Signed-off-by: Mark Adler > > > > Signed-off-by: Chin Liang See > > > > Signed-off-by: Ley Foon Tan > > > > > > This breaks the following tests on sandbox: > > > FAILED test/py/tests/test_efi_fit.py::test_efi_fit_launch - > > > u_boot_spawn.Timeout FAILED test/py/tests/test_fit.py::test_fit - > > > OSError: [Errno 5] Input/output error > > > > > Hi Tom > > > > I have tried to run the sandtest, but it failed in different test > > cases. I am run this command "./test/py/test.py --bd sandbox --build". > > Error log at bottom of email. > > > > Found that > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/lib/zlib/zlib.h > > always "#undef POSTINC", it is mean that U-boot can only support > > pre-increment? I have tried changing "#undef POSTINC" to "define > > POSTINC" and without this patch, the test failed at the same location. > > So, the failure is not caused by this patch. > > Note, this patch mainly changes to support post-increment only. > > > > Any suggestion to fix this? > > I'm not sure why the tests fail for you to start with. They all pass inn the > CI > environment as well as locally. I would start by seeing how your > environment differs from those. Hi Tom My test is running on Ubuntu 20.04 Linux. Can you try change "#undef POSTINC" to "#define POSTINC" in lib/zlib/zlib.h if you can see the error? Regards Ley Foon
Re: [PATCH] riscv: fu540: dts: Correct reg size of clint node
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > Sent: Tuesday, October 20, 2020 1:33 PM > To: u-boot@lists.denx.de; atish.pa...@wdc.com; palmerdabb...@google.com; > bmeng...@gmail.com; paul.walms...@sifive.com > Cc: anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); > Pragnesh Patel; Bin Meng; Jagan Teki; Sean Anderson > Subject: [PATCH] riscv: fu540: dts: Correct reg size of clint node > > Signed-off-by: Pragnesh Patel > --- > arch/riscv/dts/fu540-c000-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH 1/3] riscv: Add timer_get_us() for tracing
Hi Pragnesh
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, September 11, 2020 2:48 PM
> To: Pragnesh Patel
> Cc: U-Boot Mailing List; Atish Patra; Anup Patel; Sagar Kadam; Rick Jian-Zhi
> Chen(陳建志); Paul Walmsley; Bin Meng; Lukas Auer; Sean Anderson
> Subject: Re: [PATCH 1/3] riscv: Add timer_get_us() for tracing
>
> Hi Pragnesh,
>
> On Mon, Aug 24, 2020 at 10:45 PM Pragnesh Patel
> wrote:
> >
> > timer_get_us() will use timer_ops->get_count() function for timer counter.
> > For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide a timer counter and
> > For M-mode U-Boot, mtime register will provide the same.
> >
> > Signed-off-by: Pragnesh Patel
> > ---
> > arch/riscv/lib/Makefile | 1 +
> > arch/riscv/lib/timer.c | 50 +
> > 2 files changed, 51 insertions(+)
> > create mode 100644 arch/riscv/lib/timer.c
> >
> > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> > index 10ac5b06d3..fbb68e583b 100644
> > --- a/arch/riscv/lib/Makefile
> > +++ b/arch/riscv/lib/Makefile
> > @@ -26,6 +26,7 @@ obj-y += setjmp.o
> > obj-$(CONFIG_$(SPL_)SMP) += smp.o
> > obj-$(CONFIG_SPL_BUILD)+= spl.o
> > obj-y += fdt_fixup.o
> > +obj-$(CONFIG_TIMER) += timer.o
> >
> > # For building EFI apps
> > CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
> > diff --git a/arch/riscv/lib/timer.c b/arch/riscv/lib/timer.c
> > new file mode 100644
> > index 00..3e423f2805
> > --- /dev/null
> > +++ b/arch/riscv/lib/timer.c
> > @@ -0,0 +1,50 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 SiFive, Inc
> > + *
> > + * Authors:
> > + * Pragnesh Patel
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static struct udevice *timer;
> > +
> > +ulong notrace timer_get_us(void)
>
> Does the weak one in lib/time.c not work on RISC-V?
Do you have any comments about Bin's reply ?
Thanks,
Rick
>
> > +{
> > + u64 count;
> > + ulong rate;
> > + int ret;
> > +
> > + /**
> > +* gd->timer will become NULL in initr_dm(), so assign gd->timer
> > +* to other static global timer, so that timer_get_us() can use it.
> > +*/
> > + if (!timer && gd->timer)
> > + timer = (struct udevice *)gd->timer;
> > +
> > + if (timer) {
> > + ret = timer_get_count(timer, );
> > + if (ret)
> > + return ret;
> > +
> > + rate = timer_get_rate(timer);
> > + }
> > +
> > + return (ulong)count / rate;
> > +}
> > +
> > +int timer_init(void)
>
> Why is this function necessary?
>
> > +{
> > + int ret;
> > +
> > + ret = dm_timer_init();
>
> Does enabling CONFIG_TIMER_EARLY help?
>
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
>
> Regards,
> Bin
Re: [PATCH 1/2] dm: core: Add late driver remove option
On 10/21/20 1:23 AM, Tom Rini wrote: > On Wed, Oct 21, 2020 at 12:27:45AM +0200, Marek Vasut wrote: >> On 10/15/20 5:05 PM, Simon Glass wrote: >> >> [...] >> >> Add another flag to the DM core which could be assigned to drivers and >> which makes those drivers call their remove callbacks last, just before >> booting OS and after all the other drivers finished with their remove >> callbacks. This is necessary for things like clock drivers, where the >> other drivers might depend on the clock driver in their remove callbacks. >> Prime example is the mmc subsystem, which can reconfigure a card from HS >> mode to slower modes in the remove callback and for that it needs to >> reconfigure the controller clock. [...] >> arch/arm/lib/bootm.c| 1 + >> board/Marvell/octeontx2/board.c | 4 ++-- >> drivers/core/device-remove.c| 11 --- >> drivers/core/root.c | 2 ++ >> drivers/core/uclass.c | 32 +--- >> include/dm/device.h | 4 >> include/dm/uclass-internal.h| 3 ++- >> test/dm/core.c | 21 - >> test/dm/test-main.c | 30 +- >> 9 files changed, 73 insertions(+), 35 deletions(-) > > I remember seeing a similar patch before. Do you have a change log? Nothing changed since except for the octeon fix, I still require this patch in to correctly stop SD/MMC controller and then the clock before booting Linux. >>> >>> Did you see my comments on the previous version of the patch? These >>> need to be addressed. >> >> I believe all comments are addressed. What is the problem with this patch ? > > Um. This patch doesn't say "v2" or "v3" or anything, and you said the > only change you made since last posting was adding the octeon changes. > I see a bit of a thread in > https://patchwork.ozlabs.org/project/uboot/patch/20200802150640.114716-1-marek.vasut+rene...@gmail.com/ > where Simon and Stefan expanded on things and no further follow up from > you. Did you address everything in that thread? I think so.
Re: [PATCH 1/2] dm: core: Add late driver remove option
On Wed, Oct 21, 2020 at 12:27:45AM +0200, Marek Vasut wrote: > On 10/15/20 5:05 PM, Simon Glass wrote: > > [...] > > Add another flag to the DM core which could be assigned to drivers and > which makes those drivers call their remove callbacks last, just before > booting OS and after all the other drivers finished with their remove > callbacks. This is necessary for things like clock drivers, where the > other drivers might depend on the clock driver in their remove callbacks. > Prime example is the mmc subsystem, which can reconfigure a card from HS > mode to slower modes in the remove callback and for that it needs to > reconfigure the controller clock. > >> > >> [...] > >> > arch/arm/lib/bootm.c| 1 + > board/Marvell/octeontx2/board.c | 4 ++-- > drivers/core/device-remove.c| 11 --- > drivers/core/root.c | 2 ++ > drivers/core/uclass.c | 32 +--- > include/dm/device.h | 4 > include/dm/uclass-internal.h| 3 ++- > test/dm/core.c | 21 - > test/dm/test-main.c | 30 +- > 9 files changed, 73 insertions(+), 35 deletions(-) > >>> > >>> I remember seeing a similar patch before. Do you have a change log? > >> > >> Nothing changed since except for the octeon fix, I still require this > >> patch in to correctly stop SD/MMC controller and then the clock before > >> booting Linux. > > > > Did you see my comments on the previous version of the patch? These > > need to be addressed. > > I believe all comments are addressed. What is the problem with this patch ? Um. This patch doesn't say "v2" or "v3" or anything, and you said the only change you made since last posting was adding the octeon changes. I see a bit of a thread in https://patchwork.ozlabs.org/project/uboot/patch/20200802150640.114716-1-marek.vasut+rene...@gmail.com/ where Simon and Stefan expanded on things and no further follow up from you. Did you address everything in that thread? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] dm: core: Add late driver remove option
On 10/15/20 5:05 PM, Simon Glass wrote: [...] Add another flag to the DM core which could be assigned to drivers and which makes those drivers call their remove callbacks last, just before booting OS and after all the other drivers finished with their remove callbacks. This is necessary for things like clock drivers, where the other drivers might depend on the clock driver in their remove callbacks. Prime example is the mmc subsystem, which can reconfigure a card from HS mode to slower modes in the remove callback and for that it needs to reconfigure the controller clock. >> >> [...] >> arch/arm/lib/bootm.c| 1 + board/Marvell/octeontx2/board.c | 4 ++-- drivers/core/device-remove.c| 11 --- drivers/core/root.c | 2 ++ drivers/core/uclass.c | 32 +--- include/dm/device.h | 4 include/dm/uclass-internal.h| 3 ++- test/dm/core.c | 21 - test/dm/test-main.c | 30 +- 9 files changed, 73 insertions(+), 35 deletions(-) >>> >>> I remember seeing a similar patch before. Do you have a change log? >> >> Nothing changed since except for the octeon fix, I still require this >> patch in to correctly stop SD/MMC controller and then the clock before >> booting Linux. > > Did you see my comments on the previous version of the patch? These > need to be addressed. I believe all comments are addressed. What is the problem with this patch ?
Re: [PATCH 1/2] dm: core: Add late driver remove option
On 10/12/20 10:31 AM, Marek Vasut wrote: [...] >>> Add another flag to the DM core which could be assigned to drivers and >>> which makes those drivers call their remove callbacks last, just before >>> booting OS and after all the other drivers finished with their remove >>> callbacks. This is necessary for things like clock drivers, where the >>> other drivers might depend on the clock driver in their remove callbacks. >>> Prime example is the mmc subsystem, which can reconfigure a card from HS >>> mode to slower modes in the remove callback and for that it needs to >>> reconfigure the controller clock. > > [...] > >>> arch/arm/lib/bootm.c| 1 + >>> board/Marvell/octeontx2/board.c | 4 ++-- >>> drivers/core/device-remove.c| 11 --- >>> drivers/core/root.c | 2 ++ >>> drivers/core/uclass.c | 32 +--- >>> include/dm/device.h | 4 >>> include/dm/uclass-internal.h| 3 ++- >>> test/dm/core.c | 21 - >>> test/dm/test-main.c | 30 +- >>> 9 files changed, 73 insertions(+), 35 deletions(-) >> >> I remember seeing a similar patch before. Do you have a change log? > > Nothing changed since except for the octeon fix, I still require this > patch in to correctly stop SD/MMC controller and then the clock before > booting Linux. This patch is still missing from upstream, and I see no feedback. I have multiple patches depending on this functionality too, and it already missed two merge windows.
Re: [PATCH 11/11] bootm: Support string substitution in bootargs
Hi Wolfgang,
On Tue, 20 Oct 2020 at 07:26, Wolfgang Denk wrote:
>
> Dear Simon,
>
> In message
> you
> wrote:
> >
> > > At the moment we have some cumbersome constructs like
> > >set_bootargs="setenv bootargs bla ${var}"
> >
> > Yes it is a real pain. The substitution happens on first parse two, so
> > you have to put these commands in separate variables if you are
> > building things up.
>
> Come on, is it really that big a problem?
>
> You define all your needed settings (foo, bar, baz, and maybe uuid),
> and then you run a single command
>
> setenv bootargs "${foo} ${bar} %{baz} ${uuid}"
>
> ?
>
> Yes, it takes one additional step, but it's simple and does not need
> extra code.
It is actually not simple, for three reasons:
1. With zboot the args come from the kernel setup.bin and must be modified
2. With Chrome OS the args come from the kernel partition and must be
augmented / substituted
3. The above command cannot be in the same env var as anything else,
since substitution breaks in that case
So you end up with a really complicated mess of environment variables
and scripts that is barely manageable. I want it to be simple.
See here for example (this only deals with 3 above, not 1 and 2, which
would still need custom code without my series)
https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/heads/chromeos-v2013.06/include/configs/chromeos.h#204
>
> [And if someone bothered to update hush to a recent version, and
> while doing so revisited the adaptions needed for U-Boot, we could
> also do much better. IIRC, things like command substitution were
> omitted then because of the code size it would have required; given
> today's resources this might be an optional feature for many.]
Yes I agree, so long as the code size increase is not horrific.
+Tom Rini what do you think?
Regards,
Simon
Re: [PATCH 11/11] bootm: Support string substitution in bootargs
Hi Wolfgang,
On Tue, 20 Oct 2020 at 07:17, Wolfgang Denk wrote:
>
> Dear Simon,
>
> In message
> you
> wrote:
> >
> > > You add something unconditionally to common code which very few
> > > people need. U-Boot size is growing all the time because of such
> > > ... features. This may be acceptable on the systems you have in
> > > mind, but I consider this selfish.
> >
> > Did you see the Kconfig option?
>
> So you claim the size does not grow with the feature not selected?
That's what I see, except that there is some size growth due to the
refactoring / adding tests.
>
> > > Why do we have to add yet another non-standard way of substituting
> > > variables in a string? Can we not use alreay existing methonds
> > > instead?
> >
> > What sort of methods?
>
> Variable substitution?
>
> > > Why do you have to use "%U" in your template instead of for example
> > > "${uuid}" ?
> >
> > This is what Chrome OS uses, so it is easier this way, Otherwise I
> > have to replace %U with ${uuid} first.
>
> That's what I meant when I wrote "selfish" ;-)
>
> > Which code can I use to parse the ${var} thing?
>
> setenv and run ?
Will respond on other emails.
Regards,
SImon
Re: [PATCH 00/11] bootm: Support substitions in bootargs and add tests
Hi Heinrich, On Mon, 19 Oct 2020 at 08:45, Heinrich Schuchardt wrote: > > On 19.10.20 15:55, Simon Glass wrote: > > This series adds tests to the fixup_silent-linux() function and extends > > the 'zimage' command to use it. > > > > It also adds a new string-substition feature to allow bootargs to be a > > template, rather than having to build it up piece by piece with > > information obtained in a build script. > > > > It also updates zimage to use the same command-line processing. > > > > With these additions it is possible to boot Chrome OS from a U-Boot script > > on most Chromebooks. > > Hello Simon, > > could you, please, add a patch documenting the usage of the new > string-substitution feature in the HTML documentation. OK will do. I meant to send this series three weeks ago and forgot about it... Regards, Simon
Re: [PATCH 07/11] bootm: Split out bootargs environment reading / writing
Hi Wolfgang, On Mon, 19 Oct 2020 at 08:45, Wolfgang Denk wrote: > > Dear Simon, > > In message <20201019135602.3943835-8-...@chromium.org> you wrote: > ... > > > > It is also useful for zimage to use a buffer, since it does not actually > > put the Linux command line in the bootargs variable. > > ...which I consider a bug that should be fixed. OK I was wondering about that. The messy thing about zimage is that the command line comes from the setup.bin in the kernel, and then needs to be modified. So you can't just blindly use the 'bootargs' var. Perhaps that is why it wasn't done? I also feel eventually that bootm could subsume zboot given the similarities. Or maybe zboot just dies if people stop using the old boot approach? Regards, Simon
Re: [PATCH 09/11] bootm: Allow updating the bootargs in a buffer
Hi Wolfgang, On Mon, 19 Oct 2020 at 08:47, Wolfgang Denk wrote: > > Dear Simon Glass, > > In message <20201019135602.3943835-10-...@chromium.org> you wrote: > > At present we only support updating the 'bootargs' environment > > variable. Add another function to update a buffer instead. This will > > allow zimage to use this feature. > > I think this is the wrong way to address a problem. > > Instead, zimage should use bootargs as well. OK I can add that. But for testing purposes it is still good to be able to have the feature in a function that can be called without going through environment variables. Regards, SImon
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On Tue, Oct 20, 2020 at 12:01:02PM -0500, Alex G. wrote:
> On 10/20/20 10:54 AM, Tom Rini wrote:
> > On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
> > > On 10/20/20 9:32 AM, Tom Rini wrote:
> > > > On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
> > > > > On 10/20/20 4:07 PM, Tom Rini wrote:
> > > > > > On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> > > > > > > On 10/20/20 2:27 AM, Reuben Dowle wrote:
> > > > > > > > > > What assumptions? Any code that assumes 4 byte alignment
> > > > > > > > > > will also work
> > > > > > > > > on 8 byte alignment.
> > > > > > > > > >
> > > > > > > > > > Reverting is not the same as assuming ALIGN(...4) if
> > > > > > > > > > incoming data is not
> > > > > > > > > already aligned to 4 bytes (as was the case when I saw
> > > > > > > > > crashes).
> > > > > > > > >
> > > > > > > > > Can the incoming data _not_ be 4 byte aligned ?
> > > > > > > > > How can this be replicated ?
> > > > > > > >
> > > > > > > > In my case I have an offline signing process (separate from
> > > > > > > > build server to keep secure boot keys safe), and this runs a
> > > > > > > > script which also patches the main uboot device tree with some
> > > > > > > > extra properties, then updates main uboot dtb with kernel
> > > > > > > > signature, then finally updates the spl dtb with the uboot
> > > > > > > > signature. I think when mkimage patches the dtb with the
> > > > > > > > signatures, this results in the alignment issues (the unsigned
> > > > > > > > bootloader direct from the uboot make process does not
> > > > > > > > experience this issue).
> > > > > > > >
> > > > > > > > Possibly using mkimage to add padding would also fix the
> > > > > > > > alignment issue I see at boot time.
> > > > > > > >
> > > > > > > > > > Interesting. I had not noticed the -B parameter previously.
> > > > > > > > > > I had originally
> > > > > > > > > fixed this issue on an older version of uboot that did not
> > > > > > > > > have that option,
> > > > > > > > > and later rebased the fix to newer uboot. I would need to do
> > > > > > > > > some testing to
> > > > > > > > > see if this would fix it as well.
> > > > > > > > >
> > > > > > > > > I believe this is the way to handle this if you are building
> > > > > > > > > a custom DT for U-
> > > > > > > > > Boot -- just make sure it has the correct parameters. I think
> > > > > > > > > this is also related
> > > > > > > > > to:
> > > > > > > > > 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with
> > > > > > > > > external data")
> > > > > > > >
> > > > > > > > I will look into this, although unfortunately I am very busy
> > > > > > > > with other projects right now so can't retest th
> > > > > > >
> > > > > > > In that case, I would propose to revert this to fix existing
> > > > > > > boards in
> > > > > > > mainline, and if your tests are not successful, revisit this
> > > > > > > issue.
> > > > > > >
> > > > > > > I am rather sure what you are hitting is related to the mkimage
> > > > > > > patch
> > > > > > > above, there was a lengthy discussion on that topic before.
> > > > > >
> > > > > > This gets back to what I was saying earlier in this thread. But to
> > > > > > expand on it, we have been, but cannot, use the same variable for
> > > > > > both
> > > > > > "this is where we have the DTB at runtime to use" and "this is
> > > > > > where the
> > > > > > DTB happens to exist when we get here". For the case of "we copy
> > > > > > the
> > > > > > device tree to $address", $address must be 8 bytes aligned. For the
> > > > > > case of "we use an externally provided DTB in place" I don't like
> > > > > > the
> > > > > > idea of, and worry a lot about, assuming it's going to be 8 byte
> > > > > > aligned. But I can set that aside for the moment. That said, in
> > > > > > that
> > > > > > second case we need to set $address to where the device tree is.
> > > > >
> > > > > I don't think I understand this paragraph at all ?
> > > >
> > > > OK. Maybe I can better explain it after you walk through how changing
> > > > the "copy the DTB to this address" to be 8 byte aligned is leading to
> > > > failure, as I ask below.
> > >
> > > (gdb) print gd->fdt_blob
> > > $13 = (const void *) 0xc01cf85c
> > > (gdb) x/4x gd->fdt_blob
> > > 0xc01cf85c:0xc01b814c 0xedfe0dd0 0xa0670100 0x3800
> > >
> > > Notice how u-boot thinks fdt_blob is at 0xc01cf85c. However it was
> > > actually
> > > loaded at 0xc01cf860, as evidenced by the doodfeed signature. This is with
> > > the 8-byte alignment.
> >
> > Ah, thanks. So we're in this part of the code (conditions changed to
> > results):
> > if (TRUE) {
> > debug("%s: cannot find FDT node\n", __func__);
> >
> > /*
> > * U-Boot did not find a device tree inside the FIT image.
> > Use
> > * the U-Boot device tree instead.
> > */
> >
Re: [PATCH] nokia_rx51: disable obsolete VIDEO config
On Tue, 20 Oct 2020 10:17:07 -0400 Tom Rini tr...@konsulko.com wrote: ... > > > > Without video console support it is hard and probably impossible to > > > > debug on real N900. > > > > > > > > So do not disable video console support, it would make fixing and > > > > testing N900 stuff just more complicated. > > > > > > Then please see about converting the video driver, on top of the > > > other patches. Thanks! > > So, perhaps another way to look at this (and the rest of the series) is, > Anatolij, what needs updating for these platforms? Is it that no DM > conversion has been done for them, or not enabling CONFIG_DM_VIDEO? for at91sam9, ls1021aqds, ls1021atwr, mx6sxsabresd, mx7dsabresd and many sunxi boards DM_VIDEO conversion is missing. nokia_rx51 has DM disabled, so this is a bigger problem. And CONFIG_VIDEO can be disabled for nokia_rx51 if we remove CFB_CONSOLE CONFIG_VIDEO dependency in Kconfig, it seems. This board doesn't use display controller driver, it just configures fixed frame buffer address for CFB_CONSOLE. No DM yet: mx23evk, sansa_fuze_plus, xfi3 > It looks like for the nokia_rx51 there's no CONFIG_DM conversion done at > all yet, which is the bigger problem. But what about sunxi? Is there > some video specific conversions that need to happen, or just enabling > different options once DM is enabled? Thanks! for many sunxi variants DM_VIDEO conversion is missing. Jagan did a patch [1], but there are some simplefb related issues with it. [1] http://patchwork.ozlabs.org/project/uboot/patch/20200617202437.301108-4-ja...@amarulasolutions.com -- Anatolij
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On 10/20/20 10:54 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
On 10/20/20 9:32 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
On 10/20/20 4:07 PM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
On 10/20/20 2:27 AM, Reuben Dowle wrote:
What assumptions? Any code that assumes 4 byte alignment will also work
on 8 byte alignment.
Reverting is not the same as assuming ALIGN(...4) if incoming data is not
already aligned to 4 bytes (as was the case when I saw crashes).
Can the incoming data _not_ be 4 byte aligned ?
How can this be replicated ?
In my case I have an offline signing process (separate from build server to
keep secure boot keys safe), and this runs a script which also patches the main
uboot device tree with some extra properties, then updates main uboot dtb with
kernel signature, then finally updates the spl dtb with the uboot signature. I
think when mkimage patches the dtb with the signatures, this results in the
alignment issues (the unsigned bootloader direct from the uboot make process
does not experience this issue).
Possibly using mkimage to add padding would also fix the alignment issue I see
at boot time.
Interesting. I had not noticed the -B parameter previously. I had originally
fixed this issue on an older version of uboot that did not have that option,
and later rebased the fix to newer uboot. I would need to do some testing to
see if this would fix it as well.
I believe this is the way to handle this if you are building a custom DT for U-
Boot -- just make sure it has the correct parameters. I think this is also
related
to:
20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
I will look into this, although unfortunately I am very busy with other
projects right now so can't retest th
In that case, I would propose to revert this to fix existing boards in
mainline, and if your tests are not successful, revisit this issue.
I am rather sure what you are hitting is related to the mkimage patch
above, there was a lengthy discussion on that topic before.
This gets back to what I was saying earlier in this thread. But to
expand on it, we have been, but cannot, use the same variable for both
"this is where we have the DTB at runtime to use" and "this is where the
DTB happens to exist when we get here". For the case of "we copy the
device tree to $address", $address must be 8 bytes aligned. For the
case of "we use an externally provided DTB in place" I don't like the
idea of, and worry a lot about, assuming it's going to be 8 byte
aligned. But I can set that aside for the moment. That said, in that
second case we need to set $address to where the device tree is.
I don't think I understand this paragraph at all ?
OK. Maybe I can better explain it after you walk through how changing
the "copy the DTB to this address" to be 8 byte aligned is leading to
failure, as I ask below.
(gdb) print gd->fdt_blob
$13 = (const void *) 0xc01cf85c
(gdb) x/4x gd->fdt_blob
0xc01cf85c:0xc01b814c 0xedfe0dd0 0xa0670100 0x3800
Notice how u-boot thinks fdt_blob is at 0xc01cf85c. However it was actually
loaded at 0xc01cf860, as evidenced by the doodfeed signature. This is with
the 8-byte alignment.
Ah, thanks. So we're in this part of the code (conditions changed to results):
if (TRUE) {
debug("%s: cannot find FDT node\n", __func__);
/*
* U-Boot did not find a device tree inside the FIT image. Use
* the U-Boot device tree instead.
*/
if (TRUE)
memcpy((void *)image_info.load_addr, gd->fdt_blob,
fdt_totalsize(gd->fdt_blob));
So, our destination is what changed but gd->fdt_blob is 4 lower than the
correct value. Isn't that the problem? Or am I missing something
still? Thanks!
That is incorrect:
node = 465;
...
} else {
ret = spl_load_fit_image(info, sector, fit, base_offset,
node,_info);
I think there is confusion between the writer of the FDT and the reader.
This code is in SPL, the writer. It writes the FDT to an address I shall
call x1. The reader, which is u-boot TPL, will look at address x2.
It's obvious that for the FDT to be passed successfully, x1 == x2
## For x1:
image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 8);
(gdb) print/x (spl_image->load_addr + spl_image->size)
$19 = 0xc01cf85c
(gdb) print/x image_info->load_addr
$20 = 0xc01cf860
x1 is 0xc01cf860
## For x2:
__weak void *board_fdt_blob_setup(void)
{
/* FDT is at end of image */
fdt_blob = (ulong *)&_end;
(gdb) print &_end
$22 = (char (*)[]) 0xc01cf85c
x2 = 0xc01cf85c
As I have hopefully demonstrated, SPL and
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On Tue, Oct 20, 2020 at 09:38:52AM -0500, Alex G. wrote:
> On 10/20/20 9:32 AM, Tom Rini wrote:
> > On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
> > > On 10/20/20 4:07 PM, Tom Rini wrote:
> > > > On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> > > > > On 10/20/20 2:27 AM, Reuben Dowle wrote:
> > > > > > > > What assumptions? Any code that assumes 4 byte alignment will
> > > > > > > > also work
> > > > > > > on 8 byte alignment.
> > > > > > > >
> > > > > > > > Reverting is not the same as assuming ALIGN(...4) if incoming
> > > > > > > > data is not
> > > > > > > already aligned to 4 bytes (as was the case when I saw crashes).
> > > > > > >
> > > > > > > Can the incoming data _not_ be 4 byte aligned ?
> > > > > > > How can this be replicated ?
> > > > > >
> > > > > > In my case I have an offline signing process (separate from build
> > > > > > server to keep secure boot keys safe), and this runs a script which
> > > > > > also patches the main uboot device tree with some extra properties,
> > > > > > then updates main uboot dtb with kernel signature, then finally
> > > > > > updates the spl dtb with the uboot signature. I think when mkimage
> > > > > > patches the dtb with the signatures, this results in the alignment
> > > > > > issues (the unsigned bootloader direct from the uboot make process
> > > > > > does not experience this issue).
> > > > > >
> > > > > > Possibly using mkimage to add padding would also fix the alignment
> > > > > > issue I see at boot time.
> > > > > >
> > > > > > > > Interesting. I had not noticed the -B parameter previously. I
> > > > > > > > had originally
> > > > > > > fixed this issue on an older version of uboot that did not have
> > > > > > > that option,
> > > > > > > and later rebased the fix to newer uboot. I would need to do some
> > > > > > > testing to
> > > > > > > see if this would fix it as well.
> > > > > > >
> > > > > > > I believe this is the way to handle this if you are building a
> > > > > > > custom DT for U-
> > > > > > > Boot -- just make sure it has the correct parameters. I think
> > > > > > > this is also related
> > > > > > > to:
> > > > > > > 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external
> > > > > > > data")
> > > > > >
> > > > > > I will look into this, although unfortunately I am very busy with
> > > > > > other projects right now so can't retest th
> > > > >
> > > > > In that case, I would propose to revert this to fix existing boards in
> > > > > mainline, and if your tests are not successful, revisit this issue.
> > > > >
> > > > > I am rather sure what you are hitting is related to the mkimage patch
> > > > > above, there was a lengthy discussion on that topic before.
> > > >
> > > > This gets back to what I was saying earlier in this thread. But to
> > > > expand on it, we have been, but cannot, use the same variable for both
> > > > "this is where we have the DTB at runtime to use" and "this is where the
> > > > DTB happens to exist when we get here". For the case of "we copy the
> > > > device tree to $address", $address must be 8 bytes aligned. For the
> > > > case of "we use an externally provided DTB in place" I don't like the
> > > > idea of, and worry a lot about, assuming it's going to be 8 byte
> > > > aligned. But I can set that aside for the moment. That said, in that
> > > > second case we need to set $address to where the device tree is.
> > >
> > > I don't think I understand this paragraph at all ?
> >
> > OK. Maybe I can better explain it after you walk through how changing
> > the "copy the DTB to this address" to be 8 byte aligned is leading to
> > failure, as I ask below.
>
> (gdb) print gd->fdt_blob
> $13 = (const void *) 0xc01cf85c
> (gdb) x/4x gd->fdt_blob
> 0xc01cf85c:0xc01b814c 0xedfe0dd0 0xa0670100 0x3800
>
> Notice how u-boot thinks fdt_blob is at 0xc01cf85c. However it was actually
> loaded at 0xc01cf860, as evidenced by the doodfeed signature. This is with
> the 8-byte alignment.
Ah, thanks. So we're in this part of the code (conditions changed to results):
if (TRUE) {
debug("%s: cannot find FDT node\n", __func__);
/*
* U-Boot did not find a device tree inside the FIT image. Use
* the U-Boot device tree instead.
*/
if (TRUE)
memcpy((void *)image_info.load_addr, gd->fdt_blob,
fdt_totalsize(gd->fdt_blob));
So, our destination is what changed but gd->fdt_blob is 4 lower than the
correct value. Isn't that the problem? Or am I missing something
still? Thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH 2/4] xilinx: cmd: Add support for FRU commands
From: Siva Durga Prasad Paladugu
This patch adds support for fru commands "fru capture" and "fru display".
The fru capture parses the FRU table present at an address and stores in a
structure for later use. The fru display prints the content of captured
structured in a readable format.
As of now, it supports only common header and board area of FRU. Also, it
supports only English language code and ASCII8/BINARY formats.
fru_data variable is placed to data section because fru parser can be
called very early before bss is initialized. And also information needs to
be shared that's why it is exported via header.
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
board/xilinx/Kconfig| 8 +
board/xilinx/common/Makefile| 3 +
board/xilinx/common/fru.c | 73 +
board/xilinx/common/fru.h | 66
board/xilinx/common/fru_ops.c | 263
board/xilinx/zynqmp/MAINTAINERS | 1 +
6 files changed, 414 insertions(+)
create mode 100644 board/xilinx/common/fru.c
create mode 100644 board/xilinx/common/fru.h
create mode 100644 board/xilinx/common/fru_ops.c
diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig
index 01d7f8eac1c9..51f6d2bac8ad 100644
--- a/board/xilinx/Kconfig
+++ b/board/xilinx/Kconfig
@@ -73,3 +73,11 @@ config ZYNQ_GEM_I2C_MAC_OFFSET
Set the MAC offset for i2C.
endif
+
+config CMD_FRU
+ bool "FRU information for product"
+ help
+ This option enables FRU commands to capture and display FRU
+ information present in the device. The FRU Information is used
+ to primarily to provide "inventory" information about the boards
+ that the FRU Information Device is located on.
diff --git a/board/xilinx/common/Makefile b/board/xilinx/common/Makefile
index 3600da464b87..212028478c0e 100644
--- a/board/xilinx/common/Makefile
+++ b/board/xilinx/common/Makefile
@@ -5,3 +5,6 @@
#
obj-y += board.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_CMD_FRU) += fru.o fru_ops.o
+endif
diff --git a/board/xilinx/common/fru.c b/board/xilinx/common/fru.c
new file mode 100644
index ..0ab9f2a78bd9
--- /dev/null
+++ b/board/xilinx/common/fru.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2019 - 2020 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "fru.h"
+
+static int do_fru_capture(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ unsigned long addr;
+ char *endp;
+
+ if (argc < cmdtp->maxargs)
+ return CMD_RET_USAGE;
+
+ addr = simple_strtoul(argv[2], , 16);
+ if (*argv[1] == 0 || *endp != 0)
+ return -1;
+
+ return fru_capture(addr);
+}
+
+static int do_fru_display(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ fru_display(1);
+ return CMD_RET_SUCCESS;
+}
+
+static struct cmd_tbl cmd_fru_sub[] = {
+ U_BOOT_CMD_MKENT(capture, 3, 0, do_fru_capture, "", ""),
+ U_BOOT_CMD_MKENT(display, 2, 0, do_fru_display, "", ""),
+};
+
+static int do_fru(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct cmd_tbl *c;
+ int ret;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ c = find_cmd_tbl(argv[1], _fru_sub[0],
+ARRAY_SIZE(cmd_fru_sub));
+ if (!c)
+ return CMD_RET_USAGE;
+
+ ret = c->cmd(c, flag, argc, argv);
+
+ return cmd_process_error(c, ret);
+}
+
+/***/
+#ifdef CONFIG_SYS_LONGHELP
+static char fru_help_text[] =
+ "capture - Parse and capture FRU table present at address.\n"
+ "fru display - Displays content of FRU table that was captured using\n"
+ " fru capture command\n"
+ ;
+#endif
+
+U_BOOT_CMD(
+ fru, 3, 1, do_fru,
+ "FRU table info",
+ fru_help_text
+)
diff --git a/board/xilinx/common/fru.h b/board/xilinx/common/fru.h
new file mode 100644
index ..a0413cf7f698
--- /dev/null
+++ b/board/xilinx/common/fru.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2019 Xilinx, Inc.
+ * Siva Durga Prasad Paladugu
+ */
+
+#ifndef __FRU_H
+#define __FRU_H
+
+struct fru_common_hdr {
+ u8 version;
+ u8 off_internal;
+ u8 off_chassis;
+ u8 off_board;
+ u8 off_product;
+ u8 off_multirec;
+ u8 pad;
+ u8 crc;
+};
+
+#define FRU_BOARD_MAX_LEN 32
+
+struct fru_board_data {
+ u8 ver;
+ u8 len;
+ u8 lang_code;
+ u8 time[3];
+ u8 manufacturer_type_len;
+ u8 manufacturer_name[FRU_BOARD_MAX_LEN];
+ u8 product_name_type_len;
+ u8 product_name[FRU_BOARD_MAX_LEN];
+ u8 serial_number_type_len;
+ u8 serial_number[FRU_BOARD_MAX_LEN];
+ u8 part_number_type_len;
+
[PATCH 4/4] xilinx: board: Add FRU decoder support
FMC cards are using FRU format for card identification. That's why add
support for this format.
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 83 -
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 0d0c21ca3d40..74e81c18bd5a 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -17,6 +17,8 @@
#include
#include
+#include "fru.h"
+
#if defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
{
@@ -65,7 +67,7 @@ struct xilinx_board_description {
static int highest_id = -1;
static struct xilinx_board_description **board_info;
-#define XILINX_I2C_DETECTION_BITS 8
+#define XILINX_I2C_DETECTION_BITS sizeof(struct fru_common_hdr)
/* Variable which stores pointer to array which stores eeprom content */
struct xilinx_legacy_format {
@@ -160,6 +162,82 @@ static bool xilinx_detect_legacy(u8 *buffer)
return true;
}
+static int xilinx_read_eeprom_fru(struct udevice *dev, char *name,
+ struct xilinx_board_description *desc)
+{
+ int ret, eeprom_size;
+ u8 *fru_content;
+
+ /* FIXME this is shortcut - if eeprom type is wrong it will fail */
+ eeprom_size = i2c_eeprom_size(dev);
+
+ fru_content = calloc(1, eeprom_size);
+ if (!fru_content)
+ return -ENOMEM;
+
+ debug("%s: I2C EEPROM read pass data at %p\n", __func__,
+ fru_content);
+
+ ret = dm_i2c_read(dev, 0, (uchar *)fru_content,
+ eeprom_size);
+ if (ret) {
+ debug("%s: I2C EEPROM read failed\n", __func__);
+ free(fru_content);
+ return ret;
+ }
+
+ printf("Xilinx I2C FRU format at %s:\n", name);
+ fru_capture((unsigned long)fru_content);
+ ret = fru_display(0);
+ if (ret) {
+ printf("FRU format decoding failed.\n");
+ return ret;
+ }
+
+ if (desc->header == EEPROM_HEADER_MAGIC) {
+ debug("Information already filled\n");
+ return -EINVAL;
+ }
+
+ /* It is clear that FRU was captured and structures were filled */
+ strncpy(desc->manufacturer, (char *)fru_data.brd.manufacturer_name,
+ sizeof(desc->manufacturer));
+ strncpy(desc->name, (char *)fru_data.brd.product_name,
+ sizeof(desc->name));
+ strncpy(desc->revision, (char *)fru_data.brd.rev,
+ sizeof(desc->revision));
+ strncpy(desc->serial, (char *)fru_data.brd.serial_number,
+ sizeof(desc->serial));
+ desc->header = EEPROM_HEADER_MAGIC;
+
+ return 0;
+}
+
+static bool xilinx_detect_fru(u8 *buffer)
+{
+ u8 checksum = 0;
+ int i;
+
+ checksum = fru_checksum((u8 *)buffer, sizeof(struct fru_common_hdr));
+ if (checksum) {
+ debug("%s Common header CRC FAIL\n", __func__);
+ return false;
+ }
+
+ bool all_zeros = true;
+ /* Checksum over all zeros is also zero that's why detect this case */
+ for (i = 0; i < sizeof(struct fru_common_hdr); i++) {
+ if (buffer[i] != 0)
+ all_zeros = false;
+ }
+
+ if (all_zeros)
+ return false;
+
+ debug("%s Common header CRC PASS\n", __func__);
+ return true;
+}
+
static int xilinx_read_eeprom_single(char *name,
struct xilinx_board_description *desc)
{
@@ -184,6 +262,9 @@ static int xilinx_read_eeprom_single(char *name,
debug("%s: i2c memory detected: %s\n", __func__, name);
+ if (CONFIG_IS_ENABLED(CMD_FRU) && xilinx_detect_fru(buffer))
+ return xilinx_read_eeprom_fru(dev, name, desc);
+
if (xilinx_detect_legacy(buffer))
return xilinx_read_eeprom_legacy(dev, name, desc);
--
2.28.0
[PATCH 3/4] xilinx: cmd: Add basic fru format generator
Idea is to have something what can be used for board bringup from
generic board perspective.
There is a violation compare to spec that FRU ID is ASCII8 instead of
binary format but this is really for having something to pass boot and
boot to OS which has better generating options.
Also time should be filled properly.
For example:
fru board_gen 1000 XILINX versal-x-prc-01-revA serialX partX
There is also support for revision field which is Xilinx specific field.
Signed-off-by: Michal Simek
---
board/xilinx/common/fru.c | 20 ++-
board/xilinx/common/fru.h | 17 ++
board/xilinx/common/fru_ops.c | 101 +-
3 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/board/xilinx/common/fru.c b/board/xilinx/common/fru.c
index 0ab9f2a78bd9..ccf48723ff89 100644
--- a/board/xilinx/common/fru.c
+++ b/board/xilinx/common/fru.c
@@ -33,9 +33,23 @@ static int do_fru_display(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_SUCCESS;
}
+static int do_fru_generate(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ unsigned long addr;
+
+ if (argc < cmdtp->maxargs)
+ return CMD_RET_USAGE;
+
+ addr = simple_strtoul(argv[2], NULL, 16);
+
+ return fru_generate(addr, argv[3], argv[4], argv[5], argv[6], argv[7]);
+}
+
static struct cmd_tbl cmd_fru_sub[] = {
U_BOOT_CMD_MKENT(capture, 3, 0, do_fru_capture, "", ""),
U_BOOT_CMD_MKENT(display, 2, 0, do_fru_display, "", ""),
+ U_BOOT_CMD_MKENT(board_gen, 8, 0, do_fru_generate, "", ""),
};
static int do_fru(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -63,11 +77,15 @@ static char fru_help_text[] =
"capture - Parse and capture FRU table present at address.\n"
"fru display - Displays content of FRU table that was captured using\n"
" fru capture command\n"
+ "fru board_gen\n"
+ "- Generate FRU format with\n"
+ " board info area filled based on parameters. is\n"
+ " pointing to place where FRU is generated.\n"
;
#endif
U_BOOT_CMD(
- fru, 3, 1, do_fru,
+ fru, 8, 1, do_fru,
"FRU table info",
fru_help_text
)
diff --git a/board/xilinx/common/fru.h b/board/xilinx/common/fru.h
index a0413cf7f698..a3e652025714 100644
--- a/board/xilinx/common/fru.h
+++ b/board/xilinx/common/fru.h
@@ -20,6 +20,18 @@ struct fru_common_hdr {
#define FRU_BOARD_MAX_LEN 32
+struct __packed fru_board_info_header {
+ u8 ver;
+ u8 len;
+ u8 lang_code;
+ u8 time[3];
+};
+
+struct __packed fru_board_info_member {
+ u8 type_len;
+ u8 *name;
+};
+
struct fru_board_data {
u8 ver;
u8 len;
@@ -35,6 +47,9 @@ struct fru_board_data {
u8 part_number[FRU_BOARD_MAX_LEN];
u8 file_id_type_len;
u8 file_id[FRU_BOARD_MAX_LEN];
+ /* Xilinx custom fields */
+ u8 rev_type_len;
+ u8 rev[FRU_BOARD_MAX_LEN];
};
struct fru_table {
@@ -59,6 +74,8 @@ struct fru_table {
int fru_display(int verbose);
int fru_capture(unsigned long addr);
+int fru_generate(unsigned long addr, char *manufacturer, char *board_name,
+char *serial_no, char *part_no, char *revision);
u8 fru_checksum(u8 *addr, u8 len);
extern struct fru_table fru_data;
diff --git a/board/xilinx/common/fru_ops.c b/board/xilinx/common/fru_ops.c
index 491e92a7afba..fc3add7d93da 100644
--- a/board/xilinx/common/fru_ops.c
+++ b/board/xilinx/common/fru_ops.c
@@ -62,6 +62,103 @@ static int fru_check_type_len(u8 type_len, u8 language, u8
*type)
return len;
}
+/* Return len */
+static u8 fru_gen_type_len(u8 *addr, char *name)
+{
+ int len = strlen(name);
+ struct fru_board_info_member *member;
+
+ member = (struct fru_board_info_member *)addr;
+ member->type_len = FRU_TYPELEN_TYPE_ASCII8 << FRU_TYPELEN_TYPE_SHIFT;
+ member->type_len |= len;
+
+ debug("%lx/%lx: Add %s to 0x%lx (len 0x%x)\n", (ulong)addr,
+ (ulong)>type_len, name, (ulong)>name, len);
+ memcpy(>name, name, len);
+
+ /* Add +1 for type_len parameter */
+ return 1 + len;
+}
+
+int fru_generate(unsigned long addr, char *manufacturer, char *board_name,
+char *serial_no, char *part_no, char *revision)
+{
+ struct fru_common_hdr *header = (struct fru_common_hdr *)addr;
+ struct fru_board_info_header *board_info;
+ u8 *member;
+ u8 len, pad, modulo;
+
+ header->version = 1; /* Only version 1.0 is supported now */
+ header->off_internal = 0; /* not present */
+ header->off_chassis = 0; /* not present */
+ header->off_board = (sizeof(*header)) / 8; /* Starting offset 8 */
+ header->off_product = 0; /* not present */
+ header->off_multirec = 0; /* not present */
+ header->pad = 0;
+ /*
+* This unsigned byte
[PATCH 1/4] xilinx: common: Add Makefile to common folder
There is no need to reference files in common folder back. Simply adding Makefile to this folder does the job because this "common" location is already wired in main Makefile. Signed-off-by: Michal Simek --- board/xilinx/common/Makefile | 7 +++ board/xilinx/versal/Makefile | 1 - board/xilinx/zynq/Makefile | 1 - board/xilinx/zynqmp/Makefile | 1 - 4 files changed, 7 insertions(+), 3 deletions(-) create mode 100644 board/xilinx/common/Makefile diff --git a/board/xilinx/common/Makefile b/board/xilinx/common/Makefile new file mode 100644 index ..3600da464b87 --- /dev/null +++ b/board/xilinx/common/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# (C) Copyright 2020 Xilinx, Inc. +# Michal Simek +# + +obj-y += board.o diff --git a/board/xilinx/versal/Makefile b/board/xilinx/versal/Makefile index 90e034315406..4a46ca02d705 100644 --- a/board/xilinx/versal/Makefile +++ b/board/xilinx/versal/Makefile @@ -6,4 +6,3 @@ obj-y := board.o obj-$(CONFIG_CMD_VERSAL) += cmds.o -obj-y += ../common/board.o diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile index 096a7aceb939..856617158917 100644 --- a/board/xilinx/zynq/Makefile +++ b/board/xilinx/zynq/Makefile @@ -4,7 +4,6 @@ # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-y := board.o -obj-y += ../common/board.o ifneq ($(CONFIG_XILINX_PS_INIT_FILE),"") PS_INIT_FILE := $(shell cd $(srctree); readlink -f $(CONFIG_XILINX_PS_INIT_FILE)) diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile index 398c6aaa452a..7d8277ca4004 100644 --- a/board/xilinx/zynqmp/Makefile +++ b/board/xilinx/zynqmp/Makefile @@ -4,7 +4,6 @@ # Michal Simek obj-y := zynqmp.o -obj-y += ../common/board.o ifneq ($(CONFIG_XILINX_PS_INIT_FILE),"") PS_INIT_FILE := $(shell cd $(srctree); readlink -f $(CONFIG_XILINX_PS_INIT_FILE)) -- 2.28.0
[PATCH 0/4] Add support for I2C Legacy/FRU decoding
Hi, the whole series add support for I2C based FRU eeprom board identification. EEPROMs are referenced by nvmem alias which was suggested by Rob Herring (dt maintainer). Previous code was using chosen xlnx,eeprom property. And because no platform is setting up nvmem alias the code is doing nothing on all boards. If you want to try it and test it just choose board and define nvmem aliases and you should see similar logs like this. zcu104 with legacy format and FRU on FMC U-Boot 2020.10-00835-g819dc03ff784 (Oct 20 2020 - 12:48:12 +0200) Model: ZynqMP ZCU104 RevC Board: Xilinx ZynqMP DRAM: 2 GiB PMUFW: v1.1 Xilinx I2C Legacy format at nvmem0: Board name:zcu104 Board rev: c Board SN: 895527361843-94820 Ethernet mac: 00:0a:35:04:eb:93 Xilinx I2C FRU format at nvmem1: Manufacturer Name: XILINX Product Name: XXX-XXX Serial No: 1231 Part Number: dd File ID: U-Boot generator Revision Number: rev_A EL Level: EL2 Chip ID:zu7e WDT: Started with servicing (60s timeout) NAND: 0 MiB MMC: mmc@ff17: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In:serial@ff00 Out: serial@ff00 Err: serial@ff00 Bootmode: LVL_SHFT_SD_MODE1 Reset reason: EXTERNAL Net: ZYNQ GEM: ff0e, mdio bus ff0e, phyaddr 12, interface rgmii-id eth0: ethernet@ff0e Hit any key to stop autoboot: 0 ZynqMP> Based on https://lists.denx.de/pipermail/u-boot/2020-October/429382.html Thanks, Michal Michal Simek (3): xilinx: common: Add Makefile to common folder xilinx: cmd: Add basic fru format generator xilinx: board: Add FRU decoder support Siva Durga Prasad Paladugu (1): xilinx: cmd: Add support for FRU commands board/xilinx/Kconfig| 8 + board/xilinx/common/Makefile| 10 + board/xilinx/common/board.c | 83 +++- board/xilinx/common/fru.c | 91 board/xilinx/common/fru.h | 83 board/xilinx/common/fru_ops.c | 362 board/xilinx/versal/Makefile| 1 - board/xilinx/zynq/Makefile | 1 - board/xilinx/zynqmp/MAINTAINERS | 1 + board/xilinx/zynqmp/Makefile| 1 - 10 files changed, 637 insertions(+), 4 deletions(-) create mode 100644 board/xilinx/common/Makefile create mode 100644 board/xilinx/common/fru.c create mode 100644 board/xilinx/common/fru.h create mode 100644 board/xilinx/common/fru_ops.c -- 2.28.0
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On 10/20/20 4:32 PM, Tom Rini wrote:
> On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
>> On 10/20/20 4:07 PM, Tom Rini wrote:
>>> On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
On 10/20/20 2:27 AM, Reuben Dowle wrote:
>>> What assumptions? Any code that assumes 4 byte alignment will also work
>> on 8 byte alignment.
>>>
>>> Reverting is not the same as assuming ALIGN(...4) if incoming data is
>>> not
>> already aligned to 4 bytes (as was the case when I saw crashes).
>>
>> Can the incoming data _not_ be 4 byte aligned ?
>> How can this be replicated ?
>
> In my case I have an offline signing process (separate from build server
> to keep secure boot keys safe), and this runs a script which also patches
> the main uboot device tree with some extra properties, then updates main
> uboot dtb with kernel signature, then finally updates the spl dtb with
> the uboot signature. I think when mkimage patches the dtb with the
> signatures, this results in the alignment issues (the unsigned bootloader
> direct from the uboot make process does not experience this issue).
>
> Possibly using mkimage to add padding would also fix the alignment issue
> I see at boot time.
>
>>> Interesting. I had not noticed the -B parameter previously. I had
>>> originally
>> fixed this issue on an older version of uboot that did not have that
>> option,
>> and later rebased the fix to newer uboot. I would need to do some
>> testing to
>> see if this would fix it as well.
>>
>> I believe this is the way to handle this if you are building a custom DT
>> for U-
>> Boot -- just make sure it has the correct parameters. I think this is
>> also related
>> to:
>> 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
>
> I will look into this, although unfortunately I am very busy with other
> projects right now so can't retest th
In that case, I would propose to revert this to fix existing boards in
mainline, and if your tests are not successful, revisit this issue.
I am rather sure what you are hitting is related to the mkimage patch
above, there was a lengthy discussion on that topic before.
>>>
>>> This gets back to what I was saying earlier in this thread. But to
>>> expand on it, we have been, but cannot, use the same variable for both
>>> "this is where we have the DTB at runtime to use" and "this is where the
>>> DTB happens to exist when we get here". For the case of "we copy the
>>> device tree to $address", $address must be 8 bytes aligned. For the
>>> case of "we use an externally provided DTB in place" I don't like the
>>> idea of, and worry a lot about, assuming it's going to be 8 byte
>>> aligned. But I can set that aside for the moment. That said, in that
>>> second case we need to set $address to where the device tree is.
>>
>> I don't think I understand this paragraph at all ?
>
> OK. Maybe I can better explain it after you walk through how changing
> the "copy the DTB to this address" to be 8 byte aligned is leading to
> failure, as I ask below.
>
>>> That all said, I'm still not quite sure how you're ending up in the
>>> place you're ending up. Which if/else paths in spl_fit_append_fdt() is
>>> your exact platform hitting, and where is what in memory?
>>
>> Is this a question for me or for Reuben ?
>
> For you, the person with the current failure. Please walk me through
> how / where that function is now failing. With address values
> (approximate if you can't get the exact ones).
I currently don't have time for that, sorry. But Alex (on CC) was
debugging it yesterday, so I will defer there.
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On 10/20/20 9:32 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
On 10/20/20 4:07 PM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
On 10/20/20 2:27 AM, Reuben Dowle wrote:
What assumptions? Any code that assumes 4 byte alignment will also work
on 8 byte alignment.
Reverting is not the same as assuming ALIGN(...4) if incoming data is not
already aligned to 4 bytes (as was the case when I saw crashes).
Can the incoming data _not_ be 4 byte aligned ?
How can this be replicated ?
In my case I have an offline signing process (separate from build server to
keep secure boot keys safe), and this runs a script which also patches the main
uboot device tree with some extra properties, then updates main uboot dtb with
kernel signature, then finally updates the spl dtb with the uboot signature. I
think when mkimage patches the dtb with the signatures, this results in the
alignment issues (the unsigned bootloader direct from the uboot make process
does not experience this issue).
Possibly using mkimage to add padding would also fix the alignment issue I see
at boot time.
Interesting. I had not noticed the -B parameter previously. I had originally
fixed this issue on an older version of uboot that did not have that option,
and later rebased the fix to newer uboot. I would need to do some testing to
see if this would fix it as well.
I believe this is the way to handle this if you are building a custom DT for U-
Boot -- just make sure it has the correct parameters. I think this is also
related
to:
20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
I will look into this, although unfortunately I am very busy with other
projects right now so can't retest th
In that case, I would propose to revert this to fix existing boards in
mainline, and if your tests are not successful, revisit this issue.
I am rather sure what you are hitting is related to the mkimage patch
above, there was a lengthy discussion on that topic before.
This gets back to what I was saying earlier in this thread. But to
expand on it, we have been, but cannot, use the same variable for both
"this is where we have the DTB at runtime to use" and "this is where the
DTB happens to exist when we get here". For the case of "we copy the
device tree to $address", $address must be 8 bytes aligned. For the
case of "we use an externally provided DTB in place" I don't like the
idea of, and worry a lot about, assuming it's going to be 8 byte
aligned. But I can set that aside for the moment. That said, in that
second case we need to set $address to where the device tree is.
I don't think I understand this paragraph at all ?
OK. Maybe I can better explain it after you walk through how changing
the "copy the DTB to this address" to be 8 byte aligned is leading to
failure, as I ask below.
(gdb) print gd->fdt_blob
$13 = (const void *) 0xc01cf85c
(gdb) x/4x gd->fdt_blob
0xc01cf85c:0xc01b814c 0xedfe0dd0 0xa0670100 0x3800
Notice how u-boot thinks fdt_blob is at 0xc01cf85c. However it was
actually loaded at 0xc01cf860, as evidenced by the doodfeed signature.
This is with the 8-byte alignment.
Alex
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On Tue, Oct 20, 2020 at 04:29:36PM +0200, Marek Vasut wrote:
> On 10/20/20 4:07 PM, Tom Rini wrote:
> > On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> >> On 10/20/20 2:27 AM, Reuben Dowle wrote:
> > What assumptions? Any code that assumes 4 byte alignment will also work
> on 8 byte alignment.
> >
> > Reverting is not the same as assuming ALIGN(...4) if incoming data is
> > not
> already aligned to 4 bytes (as was the case when I saw crashes).
>
> Can the incoming data _not_ be 4 byte aligned ?
> How can this be replicated ?
> >>>
> >>> In my case I have an offline signing process (separate from build server
> >>> to keep secure boot keys safe), and this runs a script which also patches
> >>> the main uboot device tree with some extra properties, then updates main
> >>> uboot dtb with kernel signature, then finally updates the spl dtb with
> >>> the uboot signature. I think when mkimage patches the dtb with the
> >>> signatures, this results in the alignment issues (the unsigned bootloader
> >>> direct from the uboot make process does not experience this issue).
> >>>
> >>> Possibly using mkimage to add padding would also fix the alignment issue
> >>> I see at boot time.
> >>>
> > Interesting. I had not noticed the -B parameter previously. I had
> > originally
> fixed this issue on an older version of uboot that did not have that
> option,
> and later rebased the fix to newer uboot. I would need to do some
> testing to
> see if this would fix it as well.
>
> I believe this is the way to handle this if you are building a custom DT
> for U-
> Boot -- just make sure it has the correct parameters. I think this is
> also related
> to:
> 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
> >>>
> >>> I will look into this, although unfortunately I am very busy with other
> >>> projects right now so can't retest th
> >>
> >> In that case, I would propose to revert this to fix existing boards in
> >> mainline, and if your tests are not successful, revisit this issue.
> >>
> >> I am rather sure what you are hitting is related to the mkimage patch
> >> above, there was a lengthy discussion on that topic before.
> >
> > This gets back to what I was saying earlier in this thread. But to
> > expand on it, we have been, but cannot, use the same variable for both
> > "this is where we have the DTB at runtime to use" and "this is where the
> > DTB happens to exist when we get here". For the case of "we copy the
> > device tree to $address", $address must be 8 bytes aligned. For the
> > case of "we use an externally provided DTB in place" I don't like the
> > idea of, and worry a lot about, assuming it's going to be 8 byte
> > aligned. But I can set that aside for the moment. That said, in that
> > second case we need to set $address to where the device tree is.
>
> I don't think I understand this paragraph at all ?
OK. Maybe I can better explain it after you walk through how changing
the "copy the DTB to this address" to be 8 byte aligned is leading to
failure, as I ask below.
> > That all said, I'm still not quite sure how you're ending up in the
> > place you're ending up. Which if/else paths in spl_fit_append_fdt() is
> > your exact platform hitting, and where is what in memory?
>
> Is this a question for me or for Reuben ?
For you, the person with the current failure. Please walk me through
how / where that function is now failing. With address values
(approximate if you can't get the exact ones).
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On 10/20/20 4:07 PM, Tom Rini wrote:
> On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
>> On 10/20/20 2:27 AM, Reuben Dowle wrote:
> What assumptions? Any code that assumes 4 byte alignment will also work
on 8 byte alignment.
>
> Reverting is not the same as assuming ALIGN(...4) if incoming data is not
already aligned to 4 bytes (as was the case when I saw crashes).
Can the incoming data _not_ be 4 byte aligned ?
How can this be replicated ?
>>>
>>> In my case I have an offline signing process (separate from build server to
>>> keep secure boot keys safe), and this runs a script which also patches the
>>> main uboot device tree with some extra properties, then updates main uboot
>>> dtb with kernel signature, then finally updates the spl dtb with the uboot
>>> signature. I think when mkimage patches the dtb with the signatures, this
>>> results in the alignment issues (the unsigned bootloader direct from the
>>> uboot make process does not experience this issue).
>>>
>>> Possibly using mkimage to add padding would also fix the alignment issue I
>>> see at boot time.
>>>
> Interesting. I had not noticed the -B parameter previously. I had
> originally
fixed this issue on an older version of uboot that did not have that
option,
and later rebased the fix to newer uboot. I would need to do some testing
to
see if this would fix it as well.
I believe this is the way to handle this if you are building a custom DT
for U-
Boot -- just make sure it has the correct parameters. I think this is also
related
to:
20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
>>>
>>> I will look into this, although unfortunately I am very busy with other
>>> projects right now so can't retest th
>>
>> In that case, I would propose to revert this to fix existing boards in
>> mainline, and if your tests are not successful, revisit this issue.
>>
>> I am rather sure what you are hitting is related to the mkimage patch
>> above, there was a lengthy discussion on that topic before.
>
> This gets back to what I was saying earlier in this thread. But to
> expand on it, we have been, but cannot, use the same variable for both
> "this is where we have the DTB at runtime to use" and "this is where the
> DTB happens to exist when we get here". For the case of "we copy the
> device tree to $address", $address must be 8 bytes aligned. For the
> case of "we use an externally provided DTB in place" I don't like the
> idea of, and worry a lot about, assuming it's going to be 8 byte
> aligned. But I can set that aside for the moment. That said, in that
> second case we need to set $address to where the device tree is.
I don't think I understand this paragraph at all ?
> That all said, I'm still not quite sure how you're ending up in the
> place you're ending up. Which if/else paths in spl_fit_append_fdt() is
> your exact platform hitting, and where is what in memory?
Is this a question for me or for Reuben ?
Re: [PATCH] nokia_rx51: disable obsolete VIDEO config
On Tue, Oct 20, 2020 at 11:30:51AM +0200, Pali Rohár wrote: > Hello! > > On Sunday 18 October 2020 21:17:43 Tom Rini wrote: > > On Sun, Oct 18, 2020 at 10:59:36PM +0200, Pali Rohár wrote: > > > On Sunday 18 October 2020 22:54:41 Anatolij Gustschin wrote: > > > > If you need video console support, then please convert to DM_VIDEO. > > > > > > Ok, but I'm waiting until other N900 issues are fixed. There are pending > > > patches which needs to be reviewed and merged. > > > > Can you please list which? > > U-Boot is crashing and board is automatically rebooted: > > https://lists.denx.de/pipermail/u-boot/2020-August/422968.html > > Last email in that thread: > > https://lists.denx.de/pipermail/u-boot/2020-September/427704.html So there's the unresolved MMC issue, but you can work-around that it sounded like? > > And is that all of them or are there other > > issues still? > > Except above, there is another issue with i2c, details are here: > > https://lists.denx.de/pipermail/u-boot/2020-April/408526.html > > (but even without fixing this issue U-Boot works and can boot kernel, > just it is slower) > > > > Without video console support it is hard and probably impossible to > > > debug on real N900. > > > > > > So do not disable video console support, it would make fixing and > > > testing N900 stuff just more complicated. > > > > Then please see about converting the video driver, on top of the > > other patches. Thanks! So, perhaps another way to look at this (and the rest of the series) is, Anatolij, what needs updating for these platforms? Is it that no DM conversion has been done for them, or not enabling CONFIG_DM_VIDEO? It looks like for the nokia_rx51 there's no CONFIG_DM conversion done at all yet, which is the bigger problem. But what about sunxi? Is there some video specific conversions that need to happen, or just enabling different options once DM is enabled? Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On Tue, Oct 20, 2020 at 11:05:40AM +0200, Marek Vasut wrote:
> On 10/20/20 2:27 AM, Reuben Dowle wrote:
> >>> What assumptions? Any code that assumes 4 byte alignment will also work
> >> on 8 byte alignment.
> >>>
> >>> Reverting is not the same as assuming ALIGN(...4) if incoming data is not
> >> already aligned to 4 bytes (as was the case when I saw crashes).
> >>
> >> Can the incoming data _not_ be 4 byte aligned ?
> >> How can this be replicated ?
> >
> > In my case I have an offline signing process (separate from build server to
> > keep secure boot keys safe), and this runs a script which also patches the
> > main uboot device tree with some extra properties, then updates main uboot
> > dtb with kernel signature, then finally updates the spl dtb with the uboot
> > signature. I think when mkimage patches the dtb with the signatures, this
> > results in the alignment issues (the unsigned bootloader direct from the
> > uboot make process does not experience this issue).
> >
> > Possibly using mkimage to add padding would also fix the alignment issue I
> > see at boot time.
> >
> >>> Interesting. I had not noticed the -B parameter previously. I had
> >>> originally
> >> fixed this issue on an older version of uboot that did not have that
> >> option,
> >> and later rebased the fix to newer uboot. I would need to do some testing
> >> to
> >> see if this would fix it as well.
> >>
> >> I believe this is the way to handle this if you are building a custom DT
> >> for U-
> >> Boot -- just make sure it has the correct parameters. I think this is also
> >> related
> >> to:
> >> 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
> >
> > I will look into this, although unfortunately I am very busy with other
> > projects right now so can't retest th
>
> In that case, I would propose to revert this to fix existing boards in
> mainline, and if your tests are not successful, revisit this issue.
>
> I am rather sure what you are hitting is related to the mkimage patch
> above, there was a lengthy discussion on that topic before.
This gets back to what I was saying earlier in this thread. But to
expand on it, we have been, but cannot, use the same variable for both
"this is where we have the DTB at runtime to use" and "this is where the
DTB happens to exist when we get here". For the case of "we copy the
device tree to $address", $address must be 8 bytes aligned. For the
case of "we use an externally provided DTB in place" I don't like the
idea of, and worry a lot about, assuming it's going to be 8 byte
aligned. But I can set that aside for the moment. That said, in that
second case we need to set $address to where the device tree is.
That all said, I'm still not quite sure how you're ending up in the
place you're ending up. Which if/else paths in spl_fit_append_fdt() is
your exact platform hitting, and where is what in memory?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 11/11] bootm: Support string substitution in bootargs
Dear Simon,
In message
you wrote:
>
> > At the moment we have some cumbersome constructs like
> >set_bootargs="setenv bootargs bla ${var}"
>
> Yes it is a real pain. The substitution happens on first parse two, so
> you have to put these commands in separate variables if you are
> building things up.
Come on, is it really that big a problem?
You define all your needed settings (foo, bar, baz, and maybe uuid),
and then you run a single command
setenv bootargs "${foo} ${bar} %{baz} ${uuid}"
?
Yes, it takes one additional step, but it's simple and does not need
extra code.
[And if someone bothered to update hush to a recent version, and
while doing so revisited the adaptions needed for U-Boot, we could
also do much better. IIRC, things like command substitution were
omitted then because of the code size it would have required; given
today's resources this might be an optional feature for many.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
...when fits of creativity run strong, more than one programmer or
writer has been known to abandon the desktop for the more spacious
floor. - Fred Brooks, Jr.
Re: [PATCH 11/11] bootm: Support string substitution in bootargs
Dear Simon, In message you wrote: > > I did wonder about the empty env var thing. IMO it would be nice to > support empty variables, so we can distinguish between an empty one > and a missing one. What exactly is the use case for this that justifies the additional code needed to implement this feature? Please keep in mind that this is a boot loader, and we are not attending a contest for feature-completeness. [Non-random signature this time.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery
Re: [PATCH 11/11] bootm: Support string substitution in bootargs
Dear Simon,
In message
you wrote:
>
> > You add something unconditionally to common code which very few
> > people need. U-Boot size is growing all the time because of such
> > ... features. This may be acceptable on the systems you have in
> > mind, but I consider this selfish.
>
> Did you see the Kconfig option?
So you claim the size does not grow with the feature not selected?
> > Why do we have to add yet another non-standard way of substituting
> > variables in a string? Can we not use alreay existing methonds
> > instead?
>
> What sort of methods?
Variable substitution?
> > Why do you have to use "%U" in your template instead of for example
> > "${uuid}" ?
>
> This is what Chrome OS uses, so it is easier this way, Otherwise I
> have to replace %U with ${uuid} first.
That's what I meant when I wrote "selfish" ;-)
> Which code can I use to parse the ${var} thing?
setenv and run ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
My brother sent me a postcard the other day with this big sattelite
photo of the entire earth on it. On the back it said: "Wish you were
here".- Steven Wright
Re: [PATCH 3/4] common: bootm: add checks to verify if ramdisk / fdtimage overlaps OS image
On 10/20/20 8:47 PM, Tero Kristo wrote:
> On 20/10/2020 14:07, Jaehoon Chung wrote:
>> Dear Tero,
>>
>> On 6/12/20 9:41 PM, Tero Kristo wrote:
>>> These cases are typically fatal and are difficult to debug for random
>>> users. Add checks for detecting overlapping images and abort if overlap
>>> is detected.
>>
>> I have a question about your patch.. because I have confused...
>> So i want to clear what i missed.
>>
>>
>> During booting with ramdisk, my target is stopped.
>>
>> ramdisk start address = 0x270
>> size = 0x80
>> kernel start - 0x2F0
>>
>> bootm 0x2f0 0x270:0x80 0x0260
>>
>>
>> ramdisk.end is ramdisk_start + size (0x2F0)
>>
>> Then it will be used until 0x2ef, not 0x2f0.
>> When i have checked, it doesn't overwrite RD image.
>>
>>> + /* check if ramdisk overlaps OS image */
>>> + if (images.rd_start && (((ulong)images.rd_start >= start &&
>>> + (ulong)images.rd_start <= start + size) ||
>>> + ((ulong)images.rd_end >= start &&
>>> + (ulong)images.rd_end <= start + size))) {
>>> + printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
>>> + start, start + size);> + return 1;
>>> + }
>>
>> Because of hit this condition...So doesn't boot...
>>
>> I think that it needs to change the below conditions..
>>
>> images.rd_start < start + size or images.rd_start < start + size - 1.
>> images.rd_end > start or image.rd_end - 1 >= start
>
> I believe you are actually right. However, both checks for rd_end should take
> the last byte into account, and would need to change the last check to be
> images.rd_end < start + size in addition to your changes above. Also, we
> would need to add a check to see if rd_start < start && rd_end >= start +
> size in addition to everything we check here to cover every possible overlap
> scenario...
diff --git a/common/bootm.c b/common/bootm.c
index b3377490b3..36273be1cf 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -256,9 +256,11 @@ int bootm_find_images(int flag, int argc, char *const
argv[], ulong start,
/* check if ramdisk overlaps OS image */
if (images.rd_start && (((ulong)images.rd_start >= start &&
-(ulong)images.rd_start <= start + size) ||
- ((ulong)images.rd_end >= start &&
-(ulong)images.rd_end <= start + size))) {
+(ulong)images.rd_start < start + size) ||
+ ((ulong)images.rd_end > start &&
+(ulong)images.rd_end <= start + size)) ||
+ ((ulong)images.rd_start < start &&
+(ulong)images.rd_end >= start + size)) {
printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
start, start + size);
return 1;
If you're ok, then i will send patch for fixing.
Best Regards,
Jaehoon Chung
>
> -Tero
>
>>
>> If i misunderstood something, let me know, plz.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Signed-off-by: Tero Kristo
>>> ---
>>> cmd/booti.c | 2 +-
>>> cmd/bootz.c | 2 +-
>>> common/bootm.c | 29 +++--
>>> common/bootm_os.c | 4 ++--
>>> include/bootm.h | 3 ++-
>>> 5 files changed, 33 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/cmd/booti.c b/cmd/booti.c
>>> index ae37975494..6153b229cf 100644
>>> --- a/cmd/booti.c
>>> +++ b/cmd/booti.c
>>> @@ -93,7 +93,7 @@ static int booti_start(struct cmd_tbl *cmdtp, int flag,
>>> int argc,
>>> * Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
>>> * have a header that provide this informaiton.
>>> */
>>> - if (bootm_find_images(flag, argc, argv))
>>> + if (bootm_find_images(flag, argc, argv, relocated_addr, image_size))
>>> return 1;
>>> return 0;
>>> diff --git a/cmd/bootz.c b/cmd/bootz.c
>>> index bc15fd8ec4..1c8b0cf89f 100644
>>> --- a/cmd/bootz.c
>>> +++ b/cmd/bootz.c
>>> @@ -54,7 +54,7 @@ static int bootz_start(struct cmd_tbl *cmdtp, int flag,
>>> int argc,
>>> * Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
>>> * have a header that provide this informaiton.
>>> */
>>> - if (bootm_find_images(flag, argc, argv))
>>> + if (bootm_find_images(flag, argc, argv, zi_start, zi_end - zi_start))
>>> return 1;
>>> return 0;
>>> diff --git a/common/bootm.c b/common/bootm.c
>>> index 2ed7521520..247b600d9c 100644
>>> --- a/common/bootm.c
>>> +++ b/common/bootm.c
>>> @@ -228,6 +228,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int
>>> flag, int argc,
>>> * @flag: Ignored Argument
>>> * @argc: command argument count
>>> * @argv: command argument list
>>> + * @start: OS image start address
>>> + * @size: OS image size
>>> *
>>> * boot_find_images() will attempt to
[PULL] u-boot-sh/master
The following changes since commit 7ec87e4192215815b658c3f8b34e4be010103149: Merge tag 'u-boot-atmel-2021.01-b' of https://gitlab.denx.de/u-boot/custodians/u-boot-atmel (2020-10-19 09:29:05 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to b2d7a163ab6e64a9a0ffa3996470303a0744aec8: pinctrl: renesas: pfc-r8a77990: Sync PFC tables with Linux 5.9 (2020-10-20 12:56:52 +0200) Biju Das (6): spi: renesas_rpc_spi: Add R-Car Gen3 and RZ/G2 fallback compatibility string clk: renesas: r8a774a1-cpg-mssr: Add R8A774A1 RPC clock arm: renesas: Add config option for R8A774B1 SoC arm: renesas: Add config option for R8A774E1 SoC clk: renesas: Add R8A774B1 clock tables clk: renesas: Add R8A774E1 clock tables Lad Prabhakar (4): arm: renesas: Add config option for R8A774C0 SoC arm: dts: r8a774c0: Import DTS from Linux 5.9 clk: renesas: Import R8A774C0 clock tables from Linux 5.9 pinctrl: renesas: pfc-r8a77990: Sync PFC tables with Linux 5.9 arch/arm/dts/r8a774c0.dtsi| 1960 ++ arch/arm/mach-rmobile/Kconfig.64 | 14 +- drivers/clk/renesas/Kconfig | 18 + drivers/clk/renesas/Makefile |3 + drivers/clk/renesas/r8a774a1-cpg-mssr.c |4 + drivers/clk/renesas/r8a774b1-cpg-mssr.c | 336 +++ drivers/clk/renesas/r8a774c0-cpg-mssr.c | 308 ++ drivers/clk/renesas/r8a774e1-cpg-mssr.c | 358 drivers/pinctrl/renesas/pfc-r8a77990.c| 57 +-- drivers/spi/renesas_rpc_spi.c |3 +- include/dt-bindings/clock/r8a774c0-cpg-mssr.h | 61 +++ include/dt-bindings/power/r8a774c0-sysc.h | 25 ++ 12 files changed, 3118 insertions(+), 29 deletions(-) create mode 100644 arch/arm/dts/r8a774c0.dtsi create mode 100644 drivers/clk/renesas/r8a774b1-cpg-mssr.c create mode 100644 drivers/clk/renesas/r8a774c0-cpg-mssr.c create mode 100644 drivers/clk/renesas/r8a774e1-cpg-mssr.c create mode 100644 include/dt-bindings/clock/r8a774c0-cpg-mssr.h create mode 100644 include/dt-bindings/power/r8a774c0-sysc.h
U-Boot mtest Failure (read/write)
I am trying to run mtest in U-Boot to verify if my RAM (on-board DDR3 on PowerPC based boards) is working fine. However, mtest is giving following errors when I run the test: Hit any key to stop autoboot: 0 => mtest 0x4 0x4000 0xaabbccdd 0x1 Testing 0004 ... 4000: Iteration: 1 FAILURE (read/write) @ 0x08d174f4: expected 0x02345d3d, actual 0x02365d3d) FAILURE (read/write) @ 0x08d1f4ec: expected 0x02347d3b, actual 0x02357d3b) FAILURE (read/write) @ 0x08d1f4f4: expected 0x02347d3d, actual 0x02367d3d) FAILURE (read/write) @ 0x08d1f4fc: expected 0x02347d3f, actual 0x02367d3f) FAILURE (read/write) @ 0x08d274ec: expected 0x02349d3b, actual 0x02359d3b) FAILURE (read/write) @ 0x08d274fc: expected 0x02349d3f, actual 0x02369d3f) FAILURE (read/write) @ 0x2ccb62d4: expected 0x0b32d8b5, actual 0x0bb2d8b5) FAILURE (read/write): @ 0x0822d77c: expected 0xfdf74a20, actual 0xfdf74a60) FAILURE (read/write): @ 0x08d0f4c4: expected 0xfdcbc2ce, actual 0xfdcac2ce) FAILURE (read/write): @ 0x08d0f4e4: expected 0xfdcbc2c6, actual 0xfdcac2c6) FAILURE (read/write): @ 0x08d174c4: expected 0xfdcba2ce, actual 0xfdcaa2ce) FAILURE (read/write): @ 0x08d1f4cc: expected 0xfdcb82cc, actual 0xfdca82cc) FAILURE (read/write): @ 0x08d1f4e4: expected 0xfdcb82c6, actual 0xfdca82c6) FAILURE (read/write): @ 0x08d274e0: expected 0xfdcb62c7, actual 0xfdca62c7) I have run this test multiple times but the addresses on which errors occur remains almost the same ( +/- few different addresses). At first, I thought that reason of such failures can be wrong DDR timing parameters used for initializing memory controller but what made me confuse was that the errors occur on same addresses on same board on multiple retries and reboots. I have also noticed that the difference between actual and expected data is always 1-bit e.g. expected 0xfdcba2ce, actual 0xfdcaa2ce. Can anyone provide some hint what might be the reason or source of error? P.S: Running mtest on different boards results in same read/write errors but the failure addresses are different on different boards.
Re: [PATCH 3/4] common: bootm: add checks to verify if ramdisk / fdtimage overlaps OS image
On 20/10/2020 14:07, Jaehoon Chung wrote:
Dear Tero,
On 6/12/20 9:41 PM, Tero Kristo wrote:
These cases are typically fatal and are difficult to debug for random
users. Add checks for detecting overlapping images and abort if overlap
is detected.
I have a question about your patch.. because I have confused...
So i want to clear what i missed.
During booting with ramdisk, my target is stopped.
ramdisk start address = 0x270
size = 0x80
kernel start - 0x2F0
bootm 0x2f0 0x270:0x80 0x0260
ramdisk.end is ramdisk_start + size (0x2F0)
Then it will be used until 0x2ef, not 0x2f0.
When i have checked, it doesn't overwrite RD image.
+ /* check if ramdisk overlaps OS image */
+ if (images.rd_start && (((ulong)images.rd_start >= start &&
+(ulong)images.rd_start <= start + size) ||
+ ((ulong)images.rd_end >= start &&
+(ulong)images.rd_end <= start + size))) {
+ printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
+ start, start + size);> + return 1;
+ }
Because of hit this condition...So doesn't boot...
I think that it needs to change the below conditions..
images.rd_start < start + size or images.rd_start < start + size - 1.
images.rd_end > start or image.rd_end - 1 >= start
I believe you are actually right. However, both checks for rd_end should
take the last byte into account, and would need to change the last check
to be images.rd_end < start + size in addition to your changes above.
Also, we would need to add a check to see if rd_start < start && rd_end
>= start + size in addition to everything we check here to cover every
possible overlap scenario...
-Tero
If i misunderstood something, let me know, plz.
Best Regards,
Jaehoon Chung
Signed-off-by: Tero Kristo
---
cmd/booti.c | 2 +-
cmd/bootz.c | 2 +-
common/bootm.c| 29 +++--
common/bootm_os.c | 4 ++--
include/bootm.h | 3 ++-
5 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/cmd/booti.c b/cmd/booti.c
index ae37975494..6153b229cf 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -93,7 +93,7 @@ static int booti_start(struct cmd_tbl *cmdtp, int flag, int
argc,
* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
* have a header that provide this informaiton.
*/
- if (bootm_find_images(flag, argc, argv))
+ if (bootm_find_images(flag, argc, argv, relocated_addr, image_size))
return 1;
return 0;
diff --git a/cmd/bootz.c b/cmd/bootz.c
index bc15fd8ec4..1c8b0cf89f 100644
--- a/cmd/bootz.c
+++ b/cmd/bootz.c
@@ -54,7 +54,7 @@ static int bootz_start(struct cmd_tbl *cmdtp, int flag, int
argc,
* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
* have a header that provide this informaiton.
*/
- if (bootm_find_images(flag, argc, argv))
+ if (bootm_find_images(flag, argc, argv, zi_start, zi_end - zi_start))
return 1;
return 0;
diff --git a/common/bootm.c b/common/bootm.c
index 2ed7521520..247b600d9c 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -228,6 +228,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag,
int argc,
* @flag: Ignored Argument
* @argc: command argument count
* @argv: command argument list
+ * @start: OS image start address
+ * @size: OS image size
*
* boot_find_images() will attempt to load an available ramdisk,
* flattened device tree, as well as specifically marked
@@ -239,7 +241,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag,
int argc,
* 0, if all existing images were loaded correctly
* 1, if an image is found but corrupted, or invalid
*/
-int bootm_find_images(int flag, int argc, char *const argv[])
+int bootm_find_images(int flag, int argc, char *const argv[], ulong start,
+ ulong size)
{
int ret;
@@ -251,6 +254,16 @@ int bootm_find_images(int flag, int argc, char *const argv[])
return 1;
}
+ /* check if ramdisk overlaps OS image */
+ if (images.rd_start && (((ulong)images.rd_start >= start &&
+(ulong)images.rd_start <= start + size) ||
+ ((ulong)images.rd_end >= start &&
+(ulong)images.rd_end <= start + size))) {
+ printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
+ start, start + size);
+ return 1;
+ }
+
#if IMAGE_ENABLE_OF_LIBFDT
/* find flattened device tree */
ret = boot_get_fdt(flag, argc, argv, IH_ARCH_DEFAULT, ,
@@ -259,6 +272,18 @@ int bootm_find_images(int flag, int argc, char *const
argv[])
puts("Could not find a valid device tree\n");
return 1;
Re: [PATCH 3/4] common: bootm: add checks to verify if ramdisk / fdtimage overlaps OS image
Dear Tero,
On 6/12/20 9:41 PM, Tero Kristo wrote:
> These cases are typically fatal and are difficult to debug for random
> users. Add checks for detecting overlapping images and abort if overlap
> is detected.
I have a question about your patch.. because I have confused...
So i want to clear what i missed.
During booting with ramdisk, my target is stopped.
ramdisk start address = 0x270
size = 0x80
kernel start - 0x2F0
bootm 0x2f0 0x270:0x80 0x0260
ramdisk.end is ramdisk_start + size (0x2F0)
Then it will be used until 0x2ef, not 0x2f0.
When i have checked, it doesn't overwrite RD image.
> + /* check if ramdisk overlaps OS image */
> + if (images.rd_start && (((ulong)images.rd_start >= start &&
> + (ulong)images.rd_start <= start + size) ||
> + ((ulong)images.rd_end >= start &&
> + (ulong)images.rd_end <= start + size))) {
> + printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
> +start, start + size);> + return 1;
> + }
Because of hit this condition...So doesn't boot...
I think that it needs to change the below conditions..
images.rd_start < start + size or images.rd_start < start + size - 1.
images.rd_end > start or image.rd_end - 1 >= start
If i misunderstood something, let me know, plz.
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Tero Kristo
> ---
> cmd/booti.c | 2 +-
> cmd/bootz.c | 2 +-
> common/bootm.c| 29 +++--
> common/bootm_os.c | 4 ++--
> include/bootm.h | 3 ++-
> 5 files changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/cmd/booti.c b/cmd/booti.c
> index ae37975494..6153b229cf 100644
> --- a/cmd/booti.c
> +++ b/cmd/booti.c
> @@ -93,7 +93,7 @@ static int booti_start(struct cmd_tbl *cmdtp, int flag, int
> argc,
>* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
>* have a header that provide this informaiton.
>*/
> - if (bootm_find_images(flag, argc, argv))
> + if (bootm_find_images(flag, argc, argv, relocated_addr, image_size))
> return 1;
>
> return 0;
> diff --git a/cmd/bootz.c b/cmd/bootz.c
> index bc15fd8ec4..1c8b0cf89f 100644
> --- a/cmd/bootz.c
> +++ b/cmd/bootz.c
> @@ -54,7 +54,7 @@ static int bootz_start(struct cmd_tbl *cmdtp, int flag, int
> argc,
>* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
>* have a header that provide this informaiton.
>*/
> - if (bootm_find_images(flag, argc, argv))
> + if (bootm_find_images(flag, argc, argv, zi_start, zi_end - zi_start))
> return 1;
>
> return 0;
> diff --git a/common/bootm.c b/common/bootm.c
> index 2ed7521520..247b600d9c 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -228,6 +228,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag,
> int argc,
> * @flag: Ignored Argument
> * @argc: command argument count
> * @argv: command argument list
> + * @start: OS image start address
> + * @size: OS image size
> *
> * boot_find_images() will attempt to load an available ramdisk,
> * flattened device tree, as well as specifically marked
> @@ -239,7 +241,8 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int flag,
> int argc,
> * 0, if all existing images were loaded correctly
> * 1, if an image is found but corrupted, or invalid
> */
> -int bootm_find_images(int flag, int argc, char *const argv[])
> +int bootm_find_images(int flag, int argc, char *const argv[], ulong start,
> + ulong size)
> {
> int ret;
>
> @@ -251,6 +254,16 @@ int bootm_find_images(int flag, int argc, char *const
> argv[])
> return 1;
> }
>
> + /* check if ramdisk overlaps OS image */
> + if (images.rd_start && (((ulong)images.rd_start >= start &&
> + (ulong)images.rd_start <= start + size) ||
> + ((ulong)images.rd_end >= start &&
> + (ulong)images.rd_end <= start + size))) {
> + printf("ERROR: RD image overlaps OS image (OS=0x%lx..0x%lx)\n",
> +start, start + size);
> + return 1;
> + }
> +
> #if IMAGE_ENABLE_OF_LIBFDT
> /* find flattened device tree */
> ret = boot_get_fdt(flag, argc, argv, IH_ARCH_DEFAULT, ,
> @@ -259,6 +272,18 @@ int bootm_find_images(int flag, int argc, char *const
> argv[])
> puts("Could not find a valid device tree\n");
> return 1;
> }
> +
> + /* check if FDT overlaps OS image */
> + if (images.ft_addr &&
> + (((ulong)images.ft_addr >= start &&
> + (ulong)images.ft_addr <= start + size) ||
> + ((ulong)images.ft_addr + images.ft_len >= start &&
> + (ulong)images.ft_addr + images.ft_len <= start + size))) {
> +
[PULL] u-boot-usb/master
The following changes since commit 7ec87e4192215815b658c3f8b34e4be010103149: Merge tag 'u-boot-atmel-2021.01-b' of https://gitlab.denx.de/u-boot/custodians/u-boot-atmel (2020-10-19 09:29:05 -0400) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 0cd791ced96e1510b26305c20f1199ee0d980902: MAINTAINERS: add USB driver to ARM MEDIATEK (2020-10-20 00:49:05 +0200) Chance.Yang (1): usb: dwc2: Fix control OUT transfer issue Chunfeng Yun (9): dt-binding: usb: add bindings for some common properties dt-bindings: usb: mtu3: add bindings for MediaTek USB3 DRD usb: add USB_SPEED_SUPER_PLUS usb: common: add define of usb_speed_string() usb: add MediaTek USB3 DRD driver usb: gadget: Add bcdDevice for the MTU3 USB Gadget Controller arm: dts: mt8512: add usb related nodes configs: mt8512: enable fastboot and USB host related configs MAINTAINERS: add USB driver to ARM MEDIATEK Heinrich Schuchardt (1): usb: xhci: avoid type conversion of void * Naoki Hayama (1): usb: musb-new: Fix typo in caution message MAINTAINERS| 3 + Makefile | 1 + arch/arm/dts/mt8512-bm1-emmc.dts | 34 arch/arm/dts/mt8512.dtsi | 49 - configs/mt8512_bm1_emmc_defconfig | 26 +++ doc/device-tree-bindings/usb/generic.txt | 31 +++ doc/device-tree-bindings/usb/mediatek,mtu3.txt | 79 drivers/usb/Kconfig| 2 + drivers/usb/common/common.c| 8 + drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 16 +- drivers/usb/gadget/gadget_chips.h | 8 + drivers/usb/host/xhci-mem.c| 21 +- drivers/usb/mtu3/Kconfig | 44 + drivers/usb/mtu3/Makefile | 11 ++ drivers/usb/mtu3/mtu3.h| 424 +++ drivers/usb/mtu3/mtu3_core.c | 838 + drivers/usb/mtu3/mtu3_dr.h | 52 + drivers/usb/mtu3/mtu3_gadget.c | 686 +++ drivers/usb/mtu3/mtu3_gadget_ep0.c | 933 ++ drivers/usb/mtu3/mtu3_host.c | 141 + drivers/usb/mtu3/mtu3_hw_regs.h| 515 +++ drivers/usb/mtu3/mtu3_plat.c | 369 ++ drivers/usb/mtu3/mtu3_qmu.c| 505 +++ drivers/usb/mtu3/mtu3_qmu.h| 37 drivers/usb/musb-new/musb_dsps.c | 2 +- include/linux/usb/ch9.h| 5 +- 26 files changed, 4819 insertions(+), 21 deletions(-) create mode 100644 doc/device-tree-bindings/usb/generic.txt create mode 100644 doc/device-tree-bindings/usb/mediatek,mtu3.txt create mode 100644 drivers/usb/mtu3/Kconfig create mode 100644 drivers/usb/mtu3/Makefile create mode 100644 drivers/usb/mtu3/mtu3.h create mode 100644 drivers/usb/mtu3/mtu3_core.c create mode 100644 drivers/usb/mtu3/mtu3_dr.h create mode 100644 drivers/usb/mtu3/mtu3_gadget.c create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c create mode 100644 drivers/usb/mtu3/mtu3_host.c create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h create mode 100644 drivers/usb/mtu3/mtu3_plat.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.h
Re: [PATCH] usb: dwc2: add "u-boot,force-vbus-detection" for stm32
On 10/16/20 6:32 PM, Patrick DELAUNAY wrote:
> Hi Marek,
Hi,
[...]
On 10/15/20 2:49 PM, Patrick Delaunay wrote:
> On some board, the ID pin is not connected so the B session must be
> overridden with "u-boot,force_b_session_valid" but the VBus sensing
> must continue to be handle.
>
> To managed it, this patch adds a new DT field
> "u-boot,force-vbus-detection" to use with "u-boot,force_b_session_valid"
How is this solved in Linux ?
>>>
>>> It is managed by Linux DWC2 driver: it is a real OTG driver, with dual
>>> mode support and by usb framework
>>>
>>> Throught the properties
>>> _hs {
>>> usb-role-switch;
>>> };
>>>
>>> a glue treat the session and the sensing management see
>>> linux/drivers/usb/dwc2/drd.c in linux-next
>>>
>>> PS: activate_stm_id_vb_detection is also used in driver = hsotg->params.
>>>
>>> As ID pin / vbus is completly managed by the USB TYPE driver C
>>> (STUSB1600 for STMicroelectronics board) and DWC2 driver with dual
>>> role stack (host/gadget).
>>>
>>> I don't found a better solution than device tree property for this
>>> task in U-Boot as DWC2 driver don't support dual role and U-Boot don't have
>> framework for USB type C controller.
>>>
btw can you do something about that huge change in indent ? Is it
necessary ?
>>>
>>> I move all this code under activate_stm_id_vb_detection (linked to
>>> compatible "st,stm32mp1-hsotg") to avoid impact on other platform as
>>> this "sensing" properties are only support for STM32MP15X (it is
>>> linked to USB block detection integrated in SOC)
>>>
>>> And after I need to check the
>>> 1/ The usb33d-supply is required of vbus or IDPIN sensing 2/ manage
>>> Vbus sensing or override (according dt) 3/ manage IDPIN or override
>>> (according dt)
>>>
>>> I add a new property to be backward compatible (even it the
>>> combinaison is less clear) I protect regulator function call to avoid
>>> compilation
>> issue for other platform.
>>>
>>> PS: after reading the refmanual, I also split VALOEN and VALOVAL bit update
>> as it is required.
>>>
>>> So yes I think it is needed but I can split the patch to simplify the
>>> review.
>>
>> I presume you don't feel like implementing proper OTG support, right ?
>
> Yes, I am afraid of this task.
Can you take a look ?
I will pick this patch into next for now.
Re: [PATCH] nokia_rx51: disable obsolete VIDEO config
Hello! On Sunday 18 October 2020 21:17:43 Tom Rini wrote: > On Sun, Oct 18, 2020 at 10:59:36PM +0200, Pali Rohár wrote: > > On Sunday 18 October 2020 22:54:41 Anatolij Gustschin wrote: > > > If you need video console support, then please convert to DM_VIDEO. > > > > Ok, but I'm waiting until other N900 issues are fixed. There are pending > > patches which needs to be reviewed and merged. > > Can you please list which? U-Boot is crashing and board is automatically rebooted: https://lists.denx.de/pipermail/u-boot/2020-August/422968.html Last email in that thread: https://lists.denx.de/pipermail/u-boot/2020-September/427704.html > And is that all of them or are there other > issues still? Except above, there is another issue with i2c, details are here: https://lists.denx.de/pipermail/u-boot/2020-April/408526.html (but even without fixing this issue U-Boot works and can boot kernel, just it is slower) > > Without video console support it is hard and probably impossible to > > debug on real N900. > > > > So do not disable video console support, it would make fixing and > > testing N900 stuff just more complicated. > > Then please see about converting the video driver, on top of the > other patches. Thanks! > > -- > Tom
Re: [PATCH v2 0/5] mtd: pxa3xx_nand: add support for Armada 8k
Hi Stefan,
On Tue, Oct 20 2020, Stefan Roese wrote:
> On 19.10.20 07:24, Baruch Siach wrote:
>> On Sun, Oct 18 2020, Chris Packham wrote:
>>> On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach wrote:
This series adds NAND flash support to Aramda 8k systems. Patches make the
necessary changes to the pxa3xx_nand driver and DT files.
v2:
Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd:
nand:
pxa3xx: Fix not calling dev_xxx with a device")
>>>
>>> Is it worth looking at bringing in the newer marvell_nand driver from
>>> Linux? I suspect that it will be easier to keep in sync with changes
>>> for the Armada 8K. I have considered it in the past but it kind of
>>> fell off my radar.
>>
>> The kernel raw nand API has seen some significant changes recently. It
>> looks like the kernel marvell_nand driver relies on newer API. I'm not
>> sure how easy would be syncing the drivers to a degree that makes
>> porting of changes trivial. It would probably require many other changes
>> in generic U-Boot raw NAND code.
>
> I agree that without a re-sync with a more recent Linux MTD (NAND) core
> code, this task might prove complex and failure prone. And sync'ing the
> MTD core is also a pretty complex task which needs to be done very
> carefully, to not break any existing platforms. FWICT, nobody is working
> on it right now and we can't wait for this to happen and stall the
> development here. So from my point of view, I'm okay with updates to
> the current PXA NAND driver. Testing of these patches on other platforms
> would be very welcome though.
I should note that the same driver with these modifications was tested
successfully on Armada 385 systems with NAND flash and UBIFS.
Thanks,
baruch
>> Maybe Miquel can shed some light on that.
>>
>> Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked
>> "Orphaned (Since 2018-07)".
>
> Yes, this is unfortunate. Volunteers are always welcome. ;)
>
> Thanks,
> Stefan
>
>> baruch
>>
Baruch Siach (2):
arm: dts: armada-cp110-master: update nand-controller
mtd: pxa3xx_nand: remove dead code
Shmuel Hazan (3):
arm: dts: armada-cp110-slave: add missing cps_nand
mtd: pxa3xx_nand: port to use driver model
mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
arch/arm/dts/armada-cp110-master.dtsi | 15 ++-
arch/arm/dts/armada-cp110-slave.dtsi | 16 +++
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c| 179 ++
4 files changed, 124 insertions(+), 88 deletions(-)
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 0/3] phy: marvell: cp110: fix Armada 8k rev B0 boot hang
Hi Stefan,
On Tue, Oct 20 2020, Stefan Roese wrote:
> On 18.10.20 16:11, Baruch Siach wrote:
>> Boot of Armada 8040 rev B0 hangs when U-Boot attempts to initialize the PCIe
>> serdes. Adapt patches from downstream Marvell tree that move serdes
>> initialization to ATF.
>>
>> This series requires upstream ATF version 2.1 or newer.
>
> Is there a way to detect if an older ATF is installed and print
> an error message (warning) in this case?
I see no way to detect ATF version using smc_call().
Downstream Marvell ATF have the required code[1] in the 18.12.2
release[2], which is based on ATF 1.5. This is the last ATF version from
Marvell that was released on github.
[1]
https://github.com/MarvellEmbeddedProcessors/atf-marvell/commit/4db85ae088a5e2f51e9a5a671f531cb80a632067
[2]
https://github.com/MarvellEmbeddedProcessors/atf-marvell/commits/atf-v1.5-armada-18.12
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] configs: ls1088a: enable CMD_MDIO
Enable the CMD_MDIO Kconfig option by removing the "is not set" indication from all the defconfigs for this SoC. Signed-off-by: Ioana Ciornei --- configs/ls1088aqds_qspi_SECURE_BOOT_defconfig| 1 - configs/ls1088aqds_qspi_defconfig| 1 - configs/ls1088aqds_sdcard_qspi_defconfig | 1 - configs/ls1088aqds_tfa_defconfig | 1 - configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 1 - configs/ls1088ardb_qspi_defconfig| 1 - configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_sdcard_qspi_defconfig | 1 - configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_tfa_defconfig | 1 - 10 files changed, 10 deletions(-) diff --git a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig index 0d35e91fedde..84348c2554c3 100644 --- a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig @@ -31,7 +31,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index fcb7678585b9..2976162f312f 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088aqds_sdcard_qspi_defconfig b/configs/ls1088aqds_sdcard_qspi_defconfig index 6558c165fe8f..a264bc8872d8 100644 --- a/configs/ls1088aqds_sdcard_qspi_defconfig +++ b/configs/ls1088aqds_sdcard_qspi_defconfig @@ -42,7 +42,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088aqds_tfa_defconfig b/configs/ls1088aqds_tfa_defconfig index 582cd85765f2..b5f995e85f16 100644 --- a/configs/ls1088aqds_tfa_defconfig +++ b/configs/ls1088aqds_tfa_defconfig @@ -36,7 +36,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig index 4d0785ad92d7..7676a98bf818 100644 --- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig @@ -33,7 +33,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index a80f72bc9e8f..147d53cdc19a 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -34,7 +34,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig index 29aa87f55abe..7ac113fa7aeb 100644 --- a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig @@ -45,7 +45,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088ardb_sdcard_qspi_defconfig b/configs/ls1088ardb_sdcard_qspi_defconfig index 81e360734b97..9434c916d5f8 100644 --- a/configs/ls1088ardb_sdcard_qspi_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_defconfig @@ -44,7 +44,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig index 22edd9558e16..fe016ba6962d 100644 --- a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig @@ -35,7 +35,6 @@ CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 3c9719df12d4..6fa850bad096 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -37,7 +37,6 @@ CONFIG_CMD_NAND=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_MDIO is not set CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y -- 2.17.1
Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
On 10/20/20 2:27 AM, Reuben Dowle wrote:
>>> What assumptions? Any code that assumes 4 byte alignment will also work
>> on 8 byte alignment.
>>>
>>> Reverting is not the same as assuming ALIGN(...4) if incoming data is not
>> already aligned to 4 bytes (as was the case when I saw crashes).
>>
>> Can the incoming data _not_ be 4 byte aligned ?
>> How can this be replicated ?
>
> In my case I have an offline signing process (separate from build server to
> keep secure boot keys safe), and this runs a script which also patches the
> main uboot device tree with some extra properties, then updates main uboot
> dtb with kernel signature, then finally updates the spl dtb with the uboot
> signature. I think when mkimage patches the dtb with the signatures, this
> results in the alignment issues (the unsigned bootloader direct from the
> uboot make process does not experience this issue).
>
> Possibly using mkimage to add padding would also fix the alignment issue I
> see at boot time.
>
>>> Interesting. I had not noticed the -B parameter previously. I had originally
>> fixed this issue on an older version of uboot that did not have that option,
>> and later rebased the fix to newer uboot. I would need to do some testing to
>> see if this would fix it as well.
>>
>> I believe this is the way to handle this if you are building a custom DT for
>> U-
>> Boot -- just make sure it has the correct parameters. I think this is also
>> related
>> to:
>> 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")
>
> I will look into this, although unfortunately I am very busy with other
> projects right now so can't retest th
In that case, I would propose to revert this to fix existing boards in
mainline, and if your tests are not successful, revisit this issue.
I am rather sure what you are hitting is related to the mkimage patch
above, there was a lengthy discussion on that topic before.
Re: [PATCH v2 0/5] mtd: pxa3xx_nand: add support for Armada 8k
Hi Baruch,
Hi Chris,
On 19.10.20 07:24, Baruch Siach wrote:
Hi Chris,
On Sun, Oct 18 2020, Chris Packham wrote:
On Mon, Oct 19, 2020 at 1:59 AM Baruch Siach wrote:
This series adds NAND flash support to Aramda 8k systems. Patches make the
necessary changes to the pxa3xx_nand driver and DT files.
v2:
Rebase on current master. Fixes conflict with commit 661c98121d4 ("mtd: nand:
pxa3xx: Fix not calling dev_xxx with a device")
Is it worth looking at bringing in the newer marvell_nand driver from
Linux? I suspect that it will be easier to keep in sync with changes
for the Armada 8K. I have considered it in the past but it kind of
fell off my radar.
The kernel raw nand API has seen some significant changes recently. It
looks like the kernel marvell_nand driver relies on newer API. I'm not
sure how easy would be syncing the drivers to a degree that makes
porting of changes trivial. It would probably require many other changes
in generic U-Boot raw NAND code.
I agree that without a re-sync with a more recent Linux MTD (NAND) core
code, this task might prove complex and failure prone. And sync'ing the
MTD core is also a pretty complex task which needs to be done very
carefully, to not break any existing platforms. FWICT, nobody is working
on it right now and we can't wait for this to happen and stall the
development here. So from my point of view, I'm okay with updates to
the current PXA NAND driver. Testing of these patches on other platforms
would be very welcome though.
Maybe Miquel can shed some light on that.
Unfortunately, the U-Boot MAINTAINERS NAND FLASH entry is marked
"Orphaned (Since 2018-07)".
Yes, this is unfortunate. Volunteers are always welcome. ;)
Thanks,
Stefan
baruch
Baruch Siach (2):
arm: dts: armada-cp110-master: update nand-controller
mtd: pxa3xx_nand: remove dead code
Shmuel Hazan (3):
arm: dts: armada-cp110-slave: add missing cps_nand
mtd: pxa3xx_nand: port to use driver model
mtd: nand: pxa3xx: enable NAND controller if the SoC needs it
arch/arm/dts/armada-cp110-master.dtsi | 15 ++-
arch/arm/dts/armada-cp110-slave.dtsi | 16 +++
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c| 179 ++
4 files changed, 124 insertions(+), 88 deletions(-)
--
2.28.0
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH v2] cmd: fat: Use do_save() for fatwrite
do_save() function defined in fs.c also supports FAT file system
re-use the same for fatwrite command.
Also fix the FAT test script to match the expected output.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
v1->v2
* Fixed FAT test scripts
* Sandbox test results: 655 passed, 76 skipped in 127.02s (0:02:07)
v1 -
* https://patchwork.ozlabs.org/project/uboot/patch/
20200929071300.19866-1-prabhakar.mahadev-lad...@bp.renesas.com/
---
cmd/fat.c | 43 +--
test/py/tests/test_fs/test_ext.py | 6 ++---
2 files changed, 4 insertions(+), 45 deletions(-)
diff --git a/cmd/fat.c b/cmd/fat.c
index b438ce16c9..69ce1fa530 100644
--- a/cmd/fat.c
+++ b/cmd/fat.c
@@ -98,48 +98,7 @@ U_BOOT_CMD(
static int do_fat_fswrite(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- loff_t size;
- int ret;
- unsigned long addr;
- unsigned long count;
- long offset;
- struct blk_desc *dev_desc = NULL;
- struct disk_partition info;
- int dev = 0;
- int part = 1;
- void *buf;
-
- if (argc < 5)
- return cmd_usage(cmdtp);
-
- part = blk_get_device_part_str(argv[1], argv[2], _desc, , 1);
- if (part < 0)
- return 1;
-
- dev = dev_desc->devnum;
-
- if (fat_set_blk_dev(dev_desc, ) != 0) {
- printf("\n** Unable to use %s %d:%d for fatwrite **\n",
- argv[1], dev, part);
- return 1;
- }
- addr = simple_strtoul(argv[3], NULL, 16);
- count = (argc <= 5) ? 0 : simple_strtoul(argv[5], NULL, 16);
- /* offset should be a hex, but "-1" is allowed */
- offset = (argc <= 6) ? 0 : simple_strtol(argv[6], NULL, 16);
-
- buf = map_sysmem(addr, count);
- ret = file_fat_write(argv[4], buf, offset, count, );
- unmap_sysmem(buf);
- if (ret < 0) {
- printf("\n** Unable to write \"%s\" from %s %d:%d **\n",
- argv[4], argv[1], dev, part);
- return 1;
- }
-
- printf("%llu bytes written\n", size);
-
- return 0;
+ return do_save(cmdtp, flag, argc, argv, FS_TYPE_FAT);
}
U_BOOT_CMD(
diff --git a/test/py/tests/test_fs/test_ext.py
b/test/py/tests/test_fs/test_ext.py
index 6b7fc48701..dba874fc59 100644
--- a/test/py/tests/test_fs/test_ext.py
+++ b/test/py/tests/test_fs/test_ext.py
@@ -74,7 +74,7 @@ class TestFsExt(object):
'%sload host 0:0 %x /%s' % (fs_type, ADDR, MIN_FILE),
'%swrite host 0:0 %x /dir1/none/%s.w3 $filesize'
% (fs_type, ADDR, MIN_FILE)])
-assert('Unable to write "/dir1/none/' in ''.join(output))
+assert('Unable to write file /dir1/none/' in ''.join(output))
assert_fs_integrity(fs_type, fs_img)
def test_fs_ext4(self, u_boot_console, fs_obj_ext):
@@ -216,7 +216,7 @@ class TestFsExt(object):
output = u_boot_console.run_command(
'%swrite host 0:0 %x /dir1/%s.w8 0x1400 %x'
% (fs_type, ADDR, MIN_FILE, 0x10 + 0x1400))
-assert('Unable to write "/dir1' in output)
+assert('Unable to write file /dir1' in output)
assert_fs_integrity(fs_type, fs_img)
def test_fs_ext9(self, u_boot_console, fs_obj_ext):
@@ -231,7 +231,7 @@ class TestFsExt(object):
'%sload host 0:0 %x /%s' % (fs_type, ADDR, MIN_FILE),
'%swrite host 0:0 %x /dir1/%s.w9 0x1400 0x1400'
% (fs_type, ADDR, MIN_FILE)])
-assert('Unable to write "/dir1' in ''.join(output))
+assert('Unable to write file /dir1' in ''.join(output))
assert_fs_integrity(fs_type, fs_img)
def test_fs_ext10(self, u_boot_console, fs_obj_ext):
--
2.17.1
Re: [PATCH 0/3] phy: marvell: cp110: fix Armada 8k rev B0 boot hang
Hi Baruch, On 18.10.20 16:11, Baruch Siach wrote: Boot of Armada 8040 rev B0 hangs when U-Boot attempts to initialize the PCIe serdes. Adapt patches from downstream Marvell tree that move serdes initialization to ATF. This series requires upstream ATF version 2.1 or newer. Is there a way to detect if an older ATF is installed and print an error message (warning) in this case? Thanks, Stefan
Re: [PATCH 1/3] phy: marvell: cp110: let the firmware configure the comphy
On 18.10.20 21:43, Marek Behun wrote: On Sun, 18 Oct 2020 17:11:11 +0300 Baruch Siach wrote: From: Grzegorz Jaszczyk Replace all comphy initialization with appropriate smc calls. It will result with triggering synchronous exception that is handled by Secure Monitor code in EL3. Then the Secure Monitor code will dispatch each smc call (by parsing the smc function identifier) and triggers appropriate comphy initialization. This patch reworks serdes handling for: SATA, SGMII, HS-SGMII and SFI interfaces. Signed-off-by: Grzegorz Jaszczyk Reviewed-by: Igal Liberman Signed-off-by: Baruch Siach --- drivers/phy/marvell/comphy_cp110.c | 816 - 1 file changed, 89 insertions(+), 727 deletions(-) diff --git a/drivers/phy/marvell/comphy_cp110.c b/drivers/phy/marvell/comphy_cp110.c index 15e80049def6..31baa0bb3700 100644 --- a/drivers/phy/marvell/comphy_cp110.c +++ b/drivers/phy/marvell/comphy_cp110.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -22,6 +23,32 @@ DECLARE_GLOBAL_DATA_PTR; #define HPIPE_ADDR(base, lane)(SD_ADDR(base, lane) + 0x800) #define COMPHY_ADDR(base, lane) (base + 0x28 * lane) +/* Firmware related definitions used for SMC calls */ +#define MV_SIP_COMPHY_POWER_ON 0x8201 +#define MV_SIP_COMPHY_POWER_OFF0x8202 +#define MV_SIP_COMPHY_PLL_LOCK 0x8203 + +#define COMPHY_FW_MODE_FORMAT(mode)((mode) << 12) +#define COMPHY_FW_FORMAT(mode, idx, speeds)\ + (((mode) << 12) | ((idx) << 8) | ((speeds) << 2)) +#define COMPHY_SATA_MODE 0x1 +#define COMPHY_SGMII_MODE 0x2 /* SGMII 1G */ +#define COMPHY_HS_SGMII_MODE 0x3 /* SGMII 2.5G */ +#define COMPHY_USB3H_MODE 0x4 +#define COMPHY_USB3D_MODE 0x5 +#define COMPHY_PCIE_MODE 0x6 +#define COMPHY_RXAUI_MODE 0x7 +#define COMPHY_XFI_MODE0x8 +#define COMPHY_SFI_MODE0x9 +#define COMPHY_USB3_MODE 0xa +#define COMPHY_AP_MODE 0xb These same constants can be used for Armada 3720, btw... And maybe even the code itself. So if this works, after it is applied I will try to make this driver support Armada 3720 as well. Good. BTW, my opinion on using firmware calls in kernel for this changed recently, when encountering problems on EspressoBIN which were result of many people simply not upgrading the firmware... I now think kernel should not depend on the firmware for this and implement this on its own... But I think U-Boot is ok. I'm okay with these patches in general as well, but I would like to see some users testing them on their Armada 7k/8k boards. Marek? Thanks, Stefan
[PATCH] xilinx: common: Move ZYNQ_GEM_I2C_MAC_OFFSET to board Kconfig
There is no reason to have ZYNQ specific Kconfig macro in generic location to be visible for all other SoCs. That's why move it to Xilinx common location to be visible only for us. Also introduce new bool entry ZYNQ_MAC_IN_EEPROM to have also an option to disable it or enable. This has connection to code which is reading the whole content of i2c and also work with the rest of date not just with MAC address. Signed-off-by: Michal Simek --- board/xilinx/Kconfig| 17 + ...azedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 3 ++- configs/syzygy_hub_defconfig| 3 ++- configs/xilinx_zynqmp_virt_defconfig| 3 ++- drivers/misc/Kconfig| 7 --- 5 files changed, 23 insertions(+), 10 deletions(-) diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig index c80d0a881284..01d7f8eac1c9 100644 --- a/board/xilinx/Kconfig +++ b/board/xilinx/Kconfig @@ -56,3 +56,20 @@ config BOOT_SCRIPT_OFFSET default 0x7F8 if ARCH_VERSAL help Specifies distro boot script offset in NAND/NOR flash. + +config ZYNQ_MAC_IN_EEPROM + bool "Reading MAC address from EEPROM" + help + Enable this option if your MAC address is saved in eeprom and + xlnx,eeprom DT property in chosen node points to it. + +if ZYNQ_MAC_IN_EEPROM + +config ZYNQ_GEM_I2C_MAC_OFFSET + hex "Set the I2C MAC offset" + default 0x0 + depends on DM_I2C + help + Set the MAC offset for i2C. + +endif diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig index 25282ba428af..2426179d442e 100644 --- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig +++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig @@ -8,6 +8,8 @@ CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y +CONFIG_ZYNQ_MAC_IN_EEPROM=y +CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xfa CONFIG_DEFAULT_DEVICE_TREE="avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y @@ -42,7 +44,6 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y -CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xfa CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH_BAR=y diff --git a/configs/syzygy_hub_defconfig b/configs/syzygy_hub_defconfig index 8f6900661ac6..276c476baebc 100644 --- a/configs/syzygy_hub_defconfig +++ b/configs/syzygy_hub_defconfig @@ -9,6 +9,8 @@ CONFIG_SPL_STACK_R_ADDR=0x20 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xe000 CONFIG_DEBUG_UART_CLOCK=5000 +CONFIG_ZYNQ_MAC_IN_EEPROM=y +CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xFA CONFIG_DEFAULT_DEVICE_TREE="zynq-syzygy-hub" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y @@ -40,7 +42,6 @@ CONFIG_FPGA_XILINX=y CONFIG_FPGA_ZYNQPL=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_CADENCE=y -CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xFA CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_PHY_MARVELL=y diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 2370032c150a..21072249da45 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -7,6 +7,8 @@ CONFIG_DM_GPIO=y CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y +CONFIG_ZYNQ_MAC_IN_EEPROM=y +CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x20 CONFIG_PMUFW_INIT_FILE="/mnt/disk/u-boot-bins/zynqmp/pmu.bin" CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="/mnt/disk/u-boot/pmu_obj.bin" CONFIG_ZYNQMP_USB=y @@ -93,7 +95,6 @@ CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y -CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x20 CONFIG_SYS_I2C_EEPROM_ADDR=0x0 CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW=0x0 CONFIG_SUPPORT_EMMC_BOOT=y diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index b67e906a76b0..29432ae7eb43 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -376,13 +376,6 @@ config SPL_I2C_EEPROM This option is an SPL-variant of the I2C_EEPROM option. See the help of I2C_EEPROM for details. -config ZYNQ_GEM_I2C_MAC_OFFSET - hex "Set the I2C MAC offset" - default 0x0 - depends on DM_I2C - help - Set the MAC offset for i2C. - if I2C_EEPROM config SYS_I2C_EEPROM_ADDR -- 2.28.0
RE: [PATCH v3 1/2] armv8: lx2162a: Add Soc changes to support LX2162A
Hi Meenakshi, > -Original Message- > From: U-Boot On Behalf Of > meenakshi.aggar...@nxp.com > Sent: Monday, September 7, 2020 6:12 PM > To: u-boot@lists.denx.de; Priyanka Jain > Cc: Varun Sethi ; Meenakshi Aggarwal > > Subject: [PATCH v3 1/2] armv8: lx2162a: Add Soc changes to support LX2162A > > From: Meenakshi Aggarwal > > LX2162 is LX2160 based SoC, it has same die as of LX2160 > with different packaging. > > LX2162A support 64-bit 2.9GT/s DDR4 memory, i2c, micro-click module, > microSD card, eMMC support, serial console, qspi nor flash, qsgmii, > sgmii, 25g, 40g, 50g network interface, one usb 3.0 and serdes > interface to support three PCIe gen3 interface. > > Signed-off-by: Meenakshi Aggarwal > --- > arch/arm/cpu/armv8/Kconfig | 2 +- > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 39 +-- > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 5 ++ > arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 9 ++-- > arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc | 58 > ++ > .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 8 +-- > arch/arm/cpu/armv8/fsl-layerscape/lx2160a_serdes.c | 19 ++- > arch/arm/cpu/armv8/fsl-layerscape/soc.c| 10 ++-- > arch/arm/include/asm/arch-fsl-layerscape/config.h | 6 +-- > arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 4 +- > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 12 ++--- > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 7 ++- > .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 10 ++-- > drivers/ddr/fsl/Kconfig| 1 + > drivers/net/fsl-mc/Kconfig | 4 +- > drivers/net/ldpaa_eth/Makefile | 1 + > drivers/pci/Kconfig| 4 +- > drivers/pci/pcie_layerscape_ep.c | 4 +- > drivers/pci/pcie_layerscape_fixup_common.c | 7 ++- > 19 files changed, 170 insertions(+), 40 deletions(-) > > diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig > index 3655990..f247441 100644 > --- a/arch/arm/cpu/armv8/Kconfig > +++ b/arch/arm/cpu/armv8/Kconfig > @@ -115,7 +115,7 @@ config PSCI_RESET > !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \ > !TARGET_LS1046AFRWY && \ > !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \ > -!TARGET_LX2160AQDS && \ > +!TARGET_LX2160AQDS && !TARGET_LX2162AQDS && \ > !ARCH_UNIPHIER && !TARGET_S32V234EVB > help > Most armv8 systems have PSCI support enabled in EL3, either through > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > index be51b7d..4d46587 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > @@ -208,6 +208,35 @@ config ARCH_LS2080A > imply DISTRO_DEFAULTS > imply PANIC_HANG > > +config ARCH_LX2162A > + bool > + select ARMV8_SET_SMPEN > + select FSL_LSCH3 > + select NXP_LSCH3_2 > + select SYS_HAS_SERDES > + select SYS_FSL_SRDS_1 > + select SYS_FSL_SRDS_2 > + select SYS_FSL_DDR > + select SYS_FSL_DDR_LE > + select SYS_FSL_DDR_VER_50 > + select SYS_FSL_EC1 > + select SYS_FSL_EC2 > + select SYS_FSL_ERRATUM_A050106 > + select SYS_FSL_HAS_RGMII > + select SYS_FSL_HAS_SEC > + select SYS_FSL_HAS_CCN508 > + select SYS_FSL_HAS_DDR4 > + select SYS_FSL_SEC_COMPAT_5 > + select SYS_FSL_SEC_LE > + select ARCH_EARLY_INIT_R > + select BOARD_EARLY_INIT_F > + select SYS_I2C_MXC > + select RESV_RAM if GIC_V3_ITS > + imply DISTRO_DEFAULTS > + imply PANIC_HANG > + imply SCSI > + imply SCSI_AHCI > + > config ARCH_LX2160A > bool > select ARMV8_SET_SMPEN > @@ -345,7 +374,7 @@ config SYS_FSL_ERRATUM_A050106 > help > USB3.0 Receiver needs to enable fixed equalization > for each of PHY instances in an SOC. This is similar > - to erratum A-009007, but this one is for LX2160A, > + to erratum A-009007, but this one is for LX2160A and LX2162A, > and the register value is different. > > config SYS_FSL_ERRATUM_A010315 > @@ -362,6 +391,7 @@ config MAX_CPUS > default 16 if ARCH_LS2080A > default 8 if ARCH_LS1088A > default 16 if ARCH_LX2160A > + default 16 if ARCH_LX2162A > default 1 > help > Set this number to the maximum number of possible CPUs in the SoC. > @@ -491,6 +521,7 @@ config SYS_FSL_DUART_CLK_DIV > int "DUART clock divider" > default 1 if ARCH_LS1043A > default 4 if ARCH_LX2160A > + default 4 if ARCH_LX2162A > default 2 > help > This is the divider that is used to derive DUART clock from Platform > @@ -502,6 +533,7 @@ config SYS_FSL_I2C_CLK_DIV > default 4 if ARCH_LS1012A > default 4 if ARCH_LS1028A >
Re: [PATCH next] usb: mtu3: fix build error caused by dev_xxx()
On Tue, 2020-10-20 at 14:15 +0800, Bin Meng wrote:
> Hi Chunfeng,
>
> On Tue, Oct 20, 2020 at 10:22 AM Chunfeng Yun
> wrote:
> >
> > On Tue, 2020-10-20 at 00:15 +0200, Marek Vasut wrote:
> > > On 10/19/20 2:19 PM, Chunfeng Yun wrote:
> > > > Due to the following to patches:
> > > > 4a1989c0bc77 ("dm: Don't undefine dev_xxx macros")
> > > > 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
> > > >
> > > > Need include device_compat.h and no need use __maybe_unused anymore
> > > > to fix unused variable warning
> > > >
> > > > Signed-off-by: Chunfeng Yun
> > > > ---
> > > > Please squash in: ab703ebb1cc0 ("usb: add MediaTek USB3 DRD driver")
> > > > in u-boot-usb/next
> > >
> > > Applied, thanks.
> > Thank you!
> >
> > >
> > > > Sorry for inconvenience
> > >
> > > Please make use of the CI next time.
> > Is there any reference about CI I can see?
> >
>
> You can use Microsoft Azure (recommended), or Travis-CI to test your patches.
Thank you
>
> Regards,
> Bin
Re: [PATCH 2/2] mmc: fsl_esdhc: make sure delay chain locked for HS400
On 10/20/20 12:20 PM, Y.b. Lu wrote:
> Hi Jaehoon,
>
>> -Original Message-
>> From: Jaehoon Chung
>> Sent: Tuesday, October 20, 2020 5:52 AM
>> To: Y.b. Lu ; u-boot@lists.denx.de; Peng Fan
>>
>> Subject: Re: [PATCH 2/2] mmc: fsl_esdhc: make sure delay chain locked for
>> HS400
>>
>> Dear Yangbo,
>>
>> On 10/16/20 12:13 PM, Yangbo Lu wrote:
>>> For eMMC HS400 mode, the DLL reset is a required step for mmc rescan.
>>> This step has not been documented in reference manual, but the RM will
>>> be fixed sooner or later.
>>>
>>> This patch is to add the step of DLL reset, and make sure delay chain
>>> locked for HS400.
>>>
>>> Fixes: db8f93672b42 ("mmc: fsl_esdhc: support eMMC HS400 mode")
>>> Signed-off-by: Yangbo Lu
>>
>> Reviewed-by: Jaehoon Chung
>>
>> Just added minor comments.
>>
>>
>>> ---
>>> drivers/mmc/fsl_esdhc.c | 28 +---
>>> include/fsl_esdhc.h | 4
>>> 2 files changed, 29 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
>>> index 68130ee..a18316e 100644
>>> --- a/drivers/mmc/fsl_esdhc.c
>>> +++ b/drivers/mmc/fsl_esdhc.c
>>> @@ -70,7 +70,9 @@ struct fsl_esdhc {
>>> uintsdtimingctl;/* SD timing control register */
>>> charreserved8[20]; /* reserved */
>>> uintdllcfg0;/* DLL config 0 register */
>>> - charreserved9[680]; /* reserved */
>>> + charreserved9[12]; /* reserved */
>>> + uintdllstat0; /* DLL status 0 register */
>>> + charreserved10[664];/* reserved */
>>> uintesdhcctl; /* eSDHC control register */
>>> };
>>>
>>> @@ -617,9 +619,11 @@ static void esdhc_exit_hs400(struct fsl_esdhc_priv
>> *priv)
>>> esdhc_tuning_block_enable(priv, false);
>>> }
>>>
>>> -static void esdhc_set_timing(struct fsl_esdhc_priv *priv, enum bus_mode
>> mode)
>>> +static int esdhc_set_timing(struct fsl_esdhc_priv *priv, enum bus_mode
>> mode)
>>> {
>>> struct fsl_esdhc *regs = priv->esdhc_regs;
>>> + ulong start;
>>> + u32 val;
>>>
>>> /* Exit HS400 mode before setting any other mode */
>>> if (esdhc_read32(>tbctl) & HS400_MODE &&
>>> @@ -640,17 +644,33 @@ static void esdhc_set_timing(struct fsl_esdhc_priv
>> *priv, enum bus_mode mode)
>>> esdhc_setbits32(>dllcfg0, DLL_FREQ_SEL);
>>>
>>> esdhc_setbits32(>dllcfg0, DLL_ENABLE);
>>> +
>>> + esdhc_setbits32(>dllcfg0, DLL_RESET);
>>> + udelay(1);
>>
>> Could you add a light comment why need to put udelay(1)?
>
> Actually this is just per fixed reference manual.
> I sent out v2 patch, to explain in commit message in case some one what to
> know why.
>
> "In previous commit to support eMMC HS400,
> db8f936 mmc: fsl_esdhc: support eMMC HS400 mode
>
> the steps to configure DLL could be found in commit message,
> 13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
> 14. Wait for delay chain to lock.
>
> these would be fixed as,
> 13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
> 13.1 Write DLLCFG0[DLL_RESET] to 1 and wait for 1us,
> then write DLLCFG0[DLL_RESET]
> 14. Wait for delay chain to lock."
>
> Thanks.
Thanks you for kindly explanation.
Best Regards,
Jaehoon Chung
>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> + esdhc_clrbits32(>dllcfg0, DLL_RESET);
>>> +
>>> + start = get_timer(0);
>>> + val = DLL_STS_SLV_LOCK;
>>> + while (!(esdhc_read32(>dllstat0) & val)) {
>>> + if (get_timer(start) > 1000) {
>>> + printf("fsl_esdhc: delay chain lock timeout\n");
>>> + return -ETIMEDOUT;
>>> + }
>>> + }
>>> +
>>> esdhc_setbits32(>tbctl, HS400_WNDW_ADJUST);
>>>
>>> esdhc_clock_control(priv, false);
>>> esdhc_flush_async_fifo(priv);
>>> }
>>> esdhc_clock_control(priv, true);
>>> + return 0;
>>> }
>>>
>>> static int esdhc_set_ios_common(struct fsl_esdhc_priv *priv, struct mmc
>> *mmc)
>>> {
>>> struct fsl_esdhc *regs = priv->esdhc_regs;
>>> + int ret;
>>>
>>> if (priv->is_sdhc_per_clk) {
>>> /* Select to use peripheral clock */
>>> @@ -667,7 +687,9 @@ static int esdhc_set_ios_common(struct
>> fsl_esdhc_priv *priv, struct mmc *mmc)
>>> set_sysctl(priv, mmc, mmc->clock);
>>>
>>> /* Set timing */
>>> - esdhc_set_timing(priv, mmc->selected_mode);
>>> + ret = esdhc_set_timing(priv, mmc->selected_mode);
>>> + if (ret)
>>> + return ret;
>>>
>>> /* Set the bus width */
>>> esdhc_clrbits32(>proctl, PROCTL_DTW_4 | PROCTL_DTW_8);
>>> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
>>> index e6f1c75..850a304 100644
>>> --- a/include/fsl_esdhc.h
>>> +++ b/include/fsl_esdhc.h
>>> @@ -187,8 +187,12 @@
>>>
>>> /* DLL config 0 register */
>>> #define DLL_ENABLE 0x8000
>>> +#define DLL_RESET
[PATCH v2 1/4] arm64: zynqmp: Add support for encryption and decryption on data blob
From: Siva Durga Prasad Paladugu
This patch adds support for encryption and decryption on a given data
blob using different key sources such as userkey(KUP), device key and
PUF key. Inorder to support this a new zynqmp command(zynqmp aes) has
been introduced.
Command:
zynqmp aes srcaddr ivaddr len aesop keysrc dstaddr [keyaddr]\n"
Encrypts or decrypts blob of data at src address and puts it\n"
back to dstaddr using key and iv at keyaddr and ivaddr\n"
respectively. keysrc values specifies from which source key\n"
has to be used, it can be User/Device/PUF key. A value of 0\n"
for KUP(user key),1 for DeviceKey and 2 for PUF key. The\n"
aesop value would specify the operationwhich can be 0 for\n"
decrypt and 1 for encrypt(1) operation\n";
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
Changes in v2:
- Fix cmd_tbl parameters
- Add - in help
arch/arm/mach-zynqmp/include/mach/sys_proto.h | 1 +
board/xilinx/zynqmp/cmds.c| 82 ++-
2 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
index f2b3ceab1358..df944bde09eb 100644
--- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
@@ -9,6 +9,7 @@
#define ZYNQMP_CSU_SILICON_VER_MASK0xF
#define KEY_PTR_LEN32
+#define IV_SIZE12
#define ZYNQMP_FPGA_BIT_AUTH_DDR 1
#define ZYNQMP_FPGA_BIT_AUTH_OCM 2
diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index c0d28a73e45d..b816af73792b 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -9,11 +9,22 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+struct aes {
+ u64 srcaddr;
+ u64 ivaddr;
+ u64 keyaddr;
+ u64 dstaddr;
+ u64 len;
+ u64 op;
+ u64 keysrc;
+};
+
static int do_zynqmp_verify_secure(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
@@ -107,6 +118,66 @@ static int do_zynqmp_mmio_write(struct cmd_tbl *cmdtp, int
flag, int argc,
return ret;
}
+static int do_zynqmp_aes(struct cmd_tbl *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct aes, aes, 1);
+ int ret;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+
+ if (zynqmp_firmware_version() <= PMUFW_V1_0) {
+ puts("ERR: PMUFW v1.0 or less is detected\n");
+ puts("ERR: Encrypt/Decrypt feature is not supported\n");
+ puts("ERR: Please upgrade PMUFW\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc < cmdtp->maxargs - 1)
+ return CMD_RET_USAGE;
+
+ aes->srcaddr = simple_strtoul(argv[2], NULL, 16);
+ aes->ivaddr = simple_strtoul(argv[3], NULL, 16);
+ aes->len = simple_strtoul(argv[4], NULL, 16);
+ aes->op = simple_strtoul(argv[5], NULL, 16);
+ aes->keysrc = simple_strtoul(argv[6], NULL, 16);
+ aes->dstaddr = simple_strtoul(argv[7], NULL, 16);
+
+ flush_dcache_range((ulong)aes, (ulong)(aes) +
+ roundup(sizeof(struct aes), ARCH_DMA_MINALIGN));
+
+ if (aes->srcaddr && aes->ivaddr && aes->dstaddr) {
+ flush_dcache_range(aes->srcaddr,
+ (aes->srcaddr +
+ roundup(aes->len, ARCH_DMA_MINALIGN)));
+ flush_dcache_range(aes->ivaddr,
+ (aes->ivaddr +
+ roundup(IV_SIZE, ARCH_DMA_MINALIGN)));
+ flush_dcache_range(aes->dstaddr,
+ (aes->dstaddr +
+ roundup(aes->len, ARCH_DMA_MINALIGN)));
+ }
+
+ if (aes->keysrc == 0) {
+ if (argc < cmdtp->maxargs)
+ return CMD_RET_USAGE;
+
+ aes->keyaddr = simple_strtoul(argv[8], NULL, 16);
+ if (aes->keyaddr)
+ flush_dcache_range(aes->keyaddr,
+ (aes->keyaddr +
+ roundup(KEY_PTR_LEN,
+ ARCH_DMA_MINALIGN)));
+ }
+
+ ret = xilinx_pm_request(PM_SECURE_AES, upper_32_bits((ulong)aes),
+ lower_32_bits((ulong)aes), 0, 0, ret_payload);
+ if (ret || ret_payload[1])
+ printf("Failed: AES op status:0x%x, errcode:0x%x\n",
+ ret, ret_payload[1]);
+
+ return ret;
+}
+
#ifdef CONFIG_DEFINE_TCM_OCM_MMAP
static int do_zynqmp_tcm_init(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
@@ -153,6 +224,7 @@ static struct cmd_tbl cmd_zynqmp_sub[] = {
Re: [PATCH v4 13/27] clk: ti: move drivers to 'ti' directory
On 19/10/20 10:16 pm, Dario Binacchi wrote:
> Add drivers/clk/ti/ folder and move all TI's code in this folder for
> better maintenance.
>
> Signed-off-by: Dario Binacchi
> ---
>
> (no changes since v1)
>
> drivers/clk/Kconfig | 40 +-
> drivers/clk/Makefile | 8 +---
> drivers/clk/ti/Kconfig| 42 +++
> drivers/clk/ti/Makefile | 12 ++
> .../clk-am3-dpll-x2.c}| 0
> .../{clk-ti-am3-dpll.c => ti/clk-am3-dpll.c} | 0
> drivers/clk/{clk-ti-ctrl.c => ti/clk-ctrl.c} | 0
> .../{clk-ti-divider.c => ti/clk-divider.c}| 2 +-
> drivers/clk/{clk-ti-gate.c => ti/clk-gate.c} | 0
> drivers/clk/{clk-ti-mux.c => ti/clk-mux.c}| 2 +-
> drivers/clk/{clk-ti-sci.c => ti/clk-sci.c}| 0
> drivers/clk/{clk-ti.c => ti/clk.c}| 2 +-
> drivers/clk/{clk-ti.h => ti/clk.h}| 0
> 13 files changed, 59 insertions(+), 49 deletions(-)
> create mode 100644 drivers/clk/ti/Kconfig
> create mode 100644 drivers/clk/ti/Makefile
> rename drivers/clk/{clk-ti-am3-dpll-x2.c => ti/clk-am3-dpll-x2.c} (100%)
> rename drivers/clk/{clk-ti-am3-dpll.c => ti/clk-am3-dpll.c} (100%)
> rename drivers/clk/{clk-ti-ctrl.c => ti/clk-ctrl.c} (100%)
> rename drivers/clk/{clk-ti-divider.c => ti/clk-divider.c} (99%)
> rename drivers/clk/{clk-ti-gate.c => ti/clk-gate.c} (100%)
> rename drivers/clk/{clk-ti-mux.c => ti/clk-mux.c} (99%)
> rename drivers/clk/{clk-ti-sci.c => ti/clk-sci.c} (100%)
> rename drivers/clk/{clk-ti.c => ti/clk.c} (96%)
> rename drivers/clk/{clk-ti.h => ti/clk.h} (100%)
Why don't we start adding the drivers directly unders drivers/clk/ti folder.
IMHO, it did not make sense to add drivers in drivers/clk and then move them to
drivers/clk/ti in the same series. I understand clk-to-sci.c. Movement of
clk-ti-sci.c can be a separate patch.
Thanks and regards,
Lokesh
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index f383e295d3..99b1254de6 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -98,45 +98,6 @@ config CLK_STM32F
> This clock driver adds support for RCC clock management
> for STM32F4 and STM32F7 SoCs.
>
> -config CLK_TI_AM3_DPLL
> - bool "TI AM33XX Digital Phase-Locked Loop (DPLL) clock drivers"
> - depends on CLK && OF_CONTROL
> - help
> - This enables the DPLL clock drivers support on AM33XX SoCs. The DPLL
> - provides all interface clocks and functional clocks to the processor.
> -
> -config CLK_TI_CTRL
> - bool "TI OMAP4 clock controller"
> - depends on CLK && OF_CONTROL
> - help
> - This enables the clock controller driver support on TI's SoCs.
> -
> -config CLK_TI_DIVIDER
> - bool "TI divider clock driver"
> - depends on CLK && OF_CONTROL && CLK_CCF
> - help
> - This enables the divider clock driver support on TI's SoCs.
> -
> -config CLK_TI_GATE
> - bool "TI gate clock driver"
> - depends on CLK && OF_CONTROL
> - help
> - This enables the gate clock driver support on TI's SoCs.
> -
> -config CLK_TI_MUX
> - bool "TI mux clock driver"
> - depends on CLK && OF_CONTROL && CLK_CCF
> - help
> - This enables the mux clock driver support on TI's SoCs.
> -
> -config CLK_TI_SCI
> - bool "TI System Control Interface (TI SCI) clock driver"
> - depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL
> - help
> - This enables the clock driver support over TI System Control Interface
> - available on some new TI's SoCs. If you wish to use clock resources
> - managed by the TI System Controller, say Y here. Otherwise, say N.
> -
> config CLK_HSDK
> bool "Enable cgu clock driver for HSDK boards"
> depends on CLK && TARGET_HSDK
> @@ -209,6 +170,7 @@ source "drivers/clk/owl/Kconfig"
> source "drivers/clk/renesas/Kconfig"
> source "drivers/clk/sunxi/Kconfig"
> source "drivers/clk/sifive/Kconfig"
> +source "drivers/clk/ti/Kconfig"
> source "drivers/clk/tegra/Kconfig"
> source "drivers/clk/uniphier/Kconfig"
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index c98aa27e71..848cfd46f5 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -13,12 +13,12 @@ obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) +=
> clk-composite.o
>
> obj-y += analogbits/
> obj-y += imx/
> +obj-y += ti/
> obj-y += tegra/
> obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> obj-$(CONFIG_ARCH_MTMIPS) += mtmips/
> obj-$(CONFIG_ARCH_MESON) += meson/
> -obj-$(CONFIG_ARCH_OMAP2PLUS) += clk-ti.o
> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> obj-$(CONFIG_ARCH_SOCFPGA) += altera/
> obj-$(CONFIG_CLK_AT91) += at91/
> @@ -48,11 +48,5 @@ obj-$(CONFIG_SANDBOX) += clk_sandbox.o
> obj-$(CONFIG_SANDBOX) += clk_sandbox_test.o
> obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
> obj-$(CONFIG_STM32H7) += clk_stm32h7.o
>
[PATCH v2 3/4] arm64: zynqmp: Add support for SHA3 command
From: T Karthik Reddy
This patch adds support for SHA3 command. It takes data blob
as input and generates 48 bytes sha3 hash value.
Signed-off-by: T Karthik Reddy
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
Changes in v2:
- fix cmd_tbl
- Add - to help
arch/arm/mach-zynqmp/include/mach/sys_proto.h | 5 ++
board/xilinx/zynqmp/cmds.c| 63 +++
2 files changed, 68 insertions(+)
diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
index d52eccc7e6e8..1c12eac715e5 100644
--- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
@@ -15,6 +15,11 @@
#define PRIV_EXPO_LEN 512
#define PUB_EXPO_LEN 4
+#define ZYNQMP_SHA3_INIT 1
+#define ZYNQMP_SHA3_UPDATE 2
+#define ZYNQMP_SHA3_FINAL 4
+#define ZYNQMP_SHA3_SIZE 48
+
#define ZYNQMP_FPGA_BIT_AUTH_DDR 1
#define ZYNQMP_FPGA_BIT_AUTH_OCM 2
#define ZYNQMP_FPGA_BIT_ENC_USR_KEY3
diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index bccba098cc48..b1dc98d076d0 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -282,6 +282,64 @@ static int do_zynqmp_rsa(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_SUCCESS;
}
+static int do_zynqmp_sha3(struct cmd_tbl *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+ u64 srcaddr;
+ u32 srclen, ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (argc != cmdtp->maxargs)
+ return CMD_RET_USAGE;
+
+ if (zynqmp_firmware_version() <= PMUFW_V1_0) {
+ puts("ERR: PMUFW v1.0 or less is detected\n");
+ puts("ERR: Encrypt/Decrypt feature is not supported\n");
+ puts("ERR: Please upgrade PMUFW\n");
+ return CMD_RET_FAILURE;
+ }
+
+ srcaddr = simple_strtoul(argv[2], NULL, 16);
+ srclen = simple_strtoul(argv[3], NULL, 16);
+
+ /* Check srcaddr or srclen != 0 */
+ if (!srcaddr || !srclen) {
+ puts("ERR: srcaddr & srclen should not be 0\n");
+ return CMD_RET_USAGE;
+ }
+
+ flush_dcache_range(srcaddr,
+ srcaddr + roundup(srclen, ARCH_DMA_MINALIGN));
+
+ ret = xilinx_pm_request(PM_SECURE_SHA, 0, 0, 0,
+ ZYNQMP_SHA3_INIT, ret_payload);
+ if (ret || ret_payload[1]) {
+ printf("Failed: SHA INIT status:0x%x, errcode:0x%x\n",
+ ret, ret_payload[1]);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = xilinx_pm_request(PM_SECURE_SHA, upper_32_bits((ulong)srcaddr),
+ lower_32_bits((ulong)srcaddr),
+ srclen, ZYNQMP_SHA3_UPDATE, ret_payload);
+ if (ret || ret_payload[1]) {
+ printf("Failed: SHA UPDATE status:0x%x, errcode:0x%x\n",
+ ret, ret_payload[1]);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = xilinx_pm_request(PM_SECURE_SHA, upper_32_bits((ulong)srcaddr),
+ lower_32_bits((ulong)srcaddr), ZYNQMP_SHA3_SIZE,
+ ZYNQMP_SHA3_FINAL, ret_payload);
+ if (ret || ret_payload[1]) {
+ printf("Failed: SHA FINAL status:0x%x, errcode:0x%x\n",
+ ret, ret_payload[1]);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
static struct cmd_tbl cmd_zynqmp_sub[] = {
U_BOOT_CMD_MKENT(secure, 5, 0, do_zynqmp_verify_secure, "", ""),
U_BOOT_CMD_MKENT(pmufw, 4, 0, do_zynqmp_pmufw, "", ""),
@@ -289,6 +347,7 @@ static struct cmd_tbl cmd_zynqmp_sub[] = {
U_BOOT_CMD_MKENT(mmio_write, 5, 0, do_zynqmp_mmio_write, "", ""),
U_BOOT_CMD_MKENT(aes, 9, 0, do_zynqmp_aes, "", ""),
U_BOOT_CMD_MKENT(rsa, 7, 0, do_zynqmp_rsa, "", ""),
+ U_BOOT_CMD_MKENT(sha3, 4, 0, do_zynqmp_sha3, "", ""),
#ifdef CONFIG_DEFINE_TCM_OCM_MMAP
U_BOOT_CMD_MKENT(tcminit, 3, 0, do_zynqmp_tcm_init, "", ""),
#endif
@@ -356,6 +415,10 @@ static char zynqmp_help_text[] =
" exp : private key exponent for RSA decryption(4096 bits)\n"
" public key exponent for RSA encryption(32 bits)\n"
" rsaop : 0 for RSA Decryption, 1 for RSA Encryption\n"
+ "zynqmp sha3 srcaddr srclen -\n"
+ " Generates sha3 hash value for data blob at srcaddr and puts\n"
+ " 48 bytes hash value into srcaddr\n"
+ " Note: srcaddr/srclen should not be 0\n"
;
#endif
--
2.28.0
[PATCH v2 2/4] arm64: zynqmp: Add support for RSA command
From: T Karthik Reddy
This patch adds support for RSA command, performs RSA encrypt &
RSA decrypt on data blob of key size.
Signed-off-by: T Karthik Reddy
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
---
Changes in v2:
- fix cmd_tbl
- Add - in help
arch/arm/mach-zynqmp/include/mach/sys_proto.h | 4 ++
board/xilinx/zynqmp/cmds.c| 72 +++
2 files changed, 76 insertions(+)
diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
index df944bde09eb..d52eccc7e6e8 100644
--- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
@@ -10,6 +10,10 @@
#define ZYNQMP_CSU_SILICON_VER_MASK0xF
#define KEY_PTR_LEN32
#define IV_SIZE12
+#define RSA_KEY_SIZE 512
+#define MODULUS_LEN512
+#define PRIV_EXPO_LEN 512
+#define PUB_EXPO_LEN 4
#define ZYNQMP_FPGA_BIT_AUTH_DDR 1
#define ZYNQMP_FPGA_BIT_AUTH_OCM 2
diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index b816af73792b..bccba098cc48 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -219,12 +219,76 @@ static int do_zynqmp_pmufw(struct cmd_tbl *cmdtp, int
flag, int argc,
return 0;
}
+static int do_zynqmp_rsa(struct cmd_tbl *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ u64 srcaddr, mod, exp;
+ u32 srclen, rsaop, size, ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (argc != cmdtp->maxargs)
+ return CMD_RET_USAGE;
+
+ if (zynqmp_firmware_version() <= PMUFW_V1_0) {
+ puts("ERR: PMUFW v1.0 or less is detected\n");
+ puts("ERR: Encrypt/Decrypt feature is not supported\n");
+ puts("ERR: Please upgrade PMUFW\n");
+ return CMD_RET_FAILURE;
+ }
+
+ srcaddr = simple_strtoul(argv[2], NULL, 16);
+ srclen = simple_strtoul(argv[3], NULL, 16);
+ if (srclen != RSA_KEY_SIZE) {
+ puts("ERR: srclen should be equal to 0x200(512 bytes)\n");
+ return CMD_RET_USAGE;
+ }
+
+ mod = simple_strtoul(argv[4], NULL, 16);
+ exp = simple_strtoul(argv[5], NULL, 16);
+ rsaop = simple_strtoul(argv[6], NULL, 16);
+ if (!(rsaop == 0 || rsaop == 1)) {
+ puts("ERR: rsaop should be either 0 or 1\n");
+ return CMD_RET_USAGE;
+ }
+
+ memcpy((void *)srcaddr + srclen, (void *)mod, MODULUS_LEN);
+
+ /*
+* For encryption we load public exponent (key size 4096-bits),
+* for decryption we load private exponent (32-bits)
+*/
+ if (rsaop) {
+ memcpy((void *)srcaddr + srclen + MODULUS_LEN,
+ (void *)exp, PUB_EXPO_LEN);
+ size = srclen + MODULUS_LEN + PUB_EXPO_LEN;
+ } else {
+ memcpy((void *)srcaddr + srclen + MODULUS_LEN,
+ (void *)exp, PRIV_EXPO_LEN);
+ size = srclen + MODULUS_LEN + PRIV_EXPO_LEN;
+ }
+
+ flush_dcache_range((ulong)srcaddr,
+ (ulong)(srcaddr) + roundup(size, ARCH_DMA_MINALIGN));
+
+ ret = xilinx_pm_request(PM_SECURE_RSA, upper_32_bits((ulong)srcaddr),
+ lower_32_bits((ulong)srcaddr), srclen, rsaop,
+ ret_payload);
+ if (ret || ret_payload[1]) {
+ printf("Failed: RSA status:0x%x, errcode:0x%x\n",
+ ret, ret_payload[1]);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
static struct cmd_tbl cmd_zynqmp_sub[] = {
U_BOOT_CMD_MKENT(secure, 5, 0, do_zynqmp_verify_secure, "", ""),
U_BOOT_CMD_MKENT(pmufw, 4, 0, do_zynqmp_pmufw, "", ""),
U_BOOT_CMD_MKENT(mmio_read, 3, 0, do_zynqmp_mmio_read, "", ""),
U_BOOT_CMD_MKENT(mmio_write, 5, 0, do_zynqmp_mmio_write, "", ""),
U_BOOT_CMD_MKENT(aes, 9, 0, do_zynqmp_aes, "", ""),
+ U_BOOT_CMD_MKENT(rsa, 7, 0, do_zynqmp_rsa, "", ""),
#ifdef CONFIG_DEFINE_TCM_OCM_MMAP
U_BOOT_CMD_MKENT(tcminit, 3, 0, do_zynqmp_tcm_init, "", ""),
#endif
@@ -284,6 +348,14 @@ static char zynqmp_help_text[] =
" lock(0)/split(1)\n"
#endif
"zynqmp pmufw address size - load PMU FW configuration object\n"
+ "zynqmp rsa srcaddr srclen mod exp rsaop -\n"
+ " Performs RSA encryption and RSA decryption on blob of data\n"
+ " at srcaddr and puts it back in srcaddr using modulus and\n"
+ " public or private exponent\n"
+ " srclen : must be key size(4096 bits)\n"
+ " exp : private key exponent for RSA decryption(4096 bits)\n"
+ " public key exponent for RSA encryption(32 bits)\n"
+ " rsaop : 0 for RSA Decryption, 1 for RSA Encryption\n"
;
#endif
--
2.28.0
[PATCH v2 4/4] arm64: zynqmp: Add support for saving sha3 key to different address
By default 48B sha3 hash value is written to srcaddr which is not the best
solution in case of that you want to use data for other operations. That's
why add key_addr optional parameters which enables to write 48B sha3 hash
value to specified address.
Signed-off-by: Michal Simek
Tested-by: Ashok Reddy Soma
---
Changes in v2:
- Include to "arm: zynqmp: Add zynqmp specific command for security
features" series
- Rebase with new - in help
board/xilinx/zynqmp/cmds.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index b1dc98d076d0..cf63ad97fab7 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -285,11 +285,11 @@ static int do_zynqmp_rsa(struct cmd_tbl *cmdtp, int flag,
int argc,
static int do_zynqmp_sha3(struct cmd_tbl *cmdtp, int flag,
int argc, char * const argv[])
{
- u64 srcaddr;
+ u64 srcaddr, hashaddr;
u32 srclen, ret_payload[PAYLOAD_ARG_CNT];
int ret;
- if (argc != cmdtp->maxargs)
+ if (argc > cmdtp->maxargs || argc < (cmdtp->maxargs - 1))
return CMD_RET_USAGE;
if (zynqmp_firmware_version() <= PMUFW_V1_0) {
@@ -302,6 +302,15 @@ static int do_zynqmp_sha3(struct cmd_tbl *cmdtp, int flag,
srcaddr = simple_strtoul(argv[2], NULL, 16);
srclen = simple_strtoul(argv[3], NULL, 16);
+ if (argc == 5) {
+ hashaddr = simple_strtoul(argv[4], NULL, 16);
+ flush_dcache_range(hashaddr,
+ hashaddr + roundup(ZYNQMP_SHA3_SIZE,
+ ARCH_DMA_MINALIGN));
+ } else {
+ hashaddr = srcaddr;
+ }
+
/* Check srcaddr or srclen != 0 */
if (!srcaddr || !srclen) {
puts("ERR: srcaddr & srclen should not be 0\n");
@@ -328,9 +337,10 @@ static int do_zynqmp_sha3(struct cmd_tbl *cmdtp, int flag,
return CMD_RET_FAILURE;
}
- ret = xilinx_pm_request(PM_SECURE_SHA, upper_32_bits((ulong)srcaddr),
- lower_32_bits((ulong)srcaddr), ZYNQMP_SHA3_SIZE,
- ZYNQMP_SHA3_FINAL, ret_payload);
+ ret = xilinx_pm_request(PM_SECURE_SHA, upper_32_bits((ulong)hashaddr),
+ lower_32_bits((ulong)hashaddr),
+ ZYNQMP_SHA3_SIZE, ZYNQMP_SHA3_FINAL,
+ ret_payload);
if (ret || ret_payload[1]) {
printf("Failed: SHA FINAL status:0x%x, errcode:0x%x\n",
ret, ret_payload[1]);
@@ -347,7 +357,7 @@ static struct cmd_tbl cmd_zynqmp_sub[] = {
U_BOOT_CMD_MKENT(mmio_write, 5, 0, do_zynqmp_mmio_write, "", ""),
U_BOOT_CMD_MKENT(aes, 9, 0, do_zynqmp_aes, "", ""),
U_BOOT_CMD_MKENT(rsa, 7, 0, do_zynqmp_rsa, "", ""),
- U_BOOT_CMD_MKENT(sha3, 4, 0, do_zynqmp_sha3, "", ""),
+ U_BOOT_CMD_MKENT(sha3, 5, 0, do_zynqmp_sha3, "", ""),
#ifdef CONFIG_DEFINE_TCM_OCM_MMAP
U_BOOT_CMD_MKENT(tcminit, 3, 0, do_zynqmp_tcm_init, "", ""),
#endif
@@ -415,9 +425,10 @@ static char zynqmp_help_text[] =
" exp : private key exponent for RSA decryption(4096 bits)\n"
" public key exponent for RSA encryption(32 bits)\n"
" rsaop : 0 for RSA Decryption, 1 for RSA Encryption\n"
- "zynqmp sha3 srcaddr srclen -\n"
+ "zynqmp sha3 srcaddr srclen [key_addr] -\n"
" Generates sha3 hash value for data blob at srcaddr and puts\n"
" 48 bytes hash value into srcaddr\n"
+ " Optional key_addr can be specified for saving sha3 hash value\n"
" Note: srcaddr/srclen should not be 0\n"
;
#endif
--
2.28.0
[PATCH v2 0/4] arm: zynqmp: Add zynqmp specific command for security features
Hi, the series is adding support for security features on zynqmp devices. Thanks, Michal Changes in v2: - Fix cmd_tbl parameters - Add - in help - fix cmd_tbl - Add - in help - fix cmd_tbl - Add - to help - Include to "arm: zynqmp: Add zynqmp specific command for security features" series - Rebase with new - in help Michal Simek (1): arm64: zynqmp: Add support for saving sha3 key to different address Siva Durga Prasad Paladugu (1): arm64: zynqmp: Add support for encryption and decryption on data blob T Karthik Reddy (2): arm64: zynqmp: Add support for RSA command arm64: zynqmp: Add support for SHA3 command arch/arm/mach-zynqmp/include/mach/sys_proto.h | 10 + board/xilinx/zynqmp/cmds.c| 228 +- 2 files changed, 237 insertions(+), 1 deletion(-) -- 2.28.0
Re: [PATCH v4 23/27] video: omap: drop domain clock enabling by SOC api
On 19/10/20 10:22 pm, Dario Binacchi wrote: > Enabling the domain clock is performed by the sysc interconnect target > module driver during the video device probing. > > Signed-off-by: Dario Binacchi > > --- > > (no changes since v3) > > Changes in v3: > - Remove clock domain enabling/disabling. > - Update the commit message. > > arch/arm/mach-omap2/am33xx/clock_am33xx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c > b/arch/arm/mach-omap2/am33xx/clock_am33xx.c > index 2427933c8b..cf71192360 100644 > --- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c > +++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c > @@ -226,7 +226,7 @@ void enable_basic_clocks(void) > >usb0clkctrl, > >emiffwclkctrl, > >emifclkctrl, > -#if CONFIG_IS_ENABLED(AM335X_LCD) > +#if CONFIG_IS_ENABLED(AM335X_LCD) && !CONFIG_IS_ENABLED(DM_VIDEO) > >lcdclkctrl, > >lcdcclkstctrl, Now that we are enabling clocks from DT, can we drop this hunk all together? Thanks and regards, Lokesh > #endif >
Re: [PATCH next] usb: mtu3: fix build error caused by dev_xxx()
Hi Chunfeng,
On Tue, Oct 20, 2020 at 10:22 AM Chunfeng Yun wrote:
>
> On Tue, 2020-10-20 at 00:15 +0200, Marek Vasut wrote:
> > On 10/19/20 2:19 PM, Chunfeng Yun wrote:
> > > Due to the following to patches:
> > > 4a1989c0bc77 ("dm: Don't undefine dev_xxx macros")
> > > 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
> > >
> > > Need include device_compat.h and no need use __maybe_unused anymore
> > > to fix unused variable warning
> > >
> > > Signed-off-by: Chunfeng Yun
> > > ---
> > > Please squash in: ab703ebb1cc0 ("usb: add MediaTek USB3 DRD driver")
> > > in u-boot-usb/next
> >
> > Applied, thanks.
> Thank you!
>
> >
> > > Sorry for inconvenience
> >
> > Please make use of the CI next time.
> Is there any reference about CI I can see?
>
You can use Microsoft Azure (recommended), or Travis-CI to test your patches.
Regards,
Bin
Re: [PATCH] riscv: fu540: dts: Correct reg size of clint node
On Tue, Oct 20, 2020 at 1:33 PM Pragnesh Patel wrote: > > Signed-off-by: Pragnesh Patel > --- > arch/riscv/dts/fu540-c000-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
