The SHA implementation is adapted from the linux kernel implementation.
[1] Commercial National Security Algorithm Suite
http://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
Signed-off-by: Reuben Dowle
---
Kconfig | 26 ++-
common/hash.c | 85
The SHA implementation is adapted from the linux kernel implementation.
[1] Commercial National Security Algorithm Suite
http://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
Signed-off-by: Reuben Dowle
---
Kconfig | 26 ++-
common/hash.c | 85
Hi,
I have attempted to submit patch to this mailing list twice, and each time
the patch appears to get lost in moderation.
Is there something extra I need to do to enable me to submit to this
mailing list (other than signing up to it)?
Thanks,
Reuben
On Fri, 17 Apr 2020 at 08:19, wrote:
>
into a mail client?
Reuben
On Mon, 20 Apr 2020 at 14:55, Rayagonda Kokatanur <
rayagonda.kokata...@broadcom.com> wrote:
> you should subscribe to mailing list -
> https://lists.denx.de/listinfo/u-boot
>
>
> On Mon, Apr 20, 2020 at 5:30 AM Reuben Dowle
> wrote:
>
>> Hi,
On Sat, 25 Apr 2020 at 03:08, Tom Rini wrote:
>
> Two general comments. First, please use CONFIG_IS_ENABLED() to test for
> the new symbols so that we won't have any growth in SPL if we have one
> of these enabled in the main binary but NOT SPL. Second, please
> make sure that all new files
Yes, it is possible to do this. The SPL will check its own DTB to check which
signatures are required.
When the FIT that the SPL will load is created with mkimage, you also pass the
SPL's dtb file, which will be patched to include the required signatures.
I am not sure if the config system has
key-name-hint = "boot-stage1-v1";
};
};
...
-Original Message-
From: Andrii Voloshyn
Sent: Monday, 14 September 2020 6:45 pm
To: Reuben Dowle
Cc: u-boot
Subject: RE: SPL FIT configuration signature verification
Hi Reuben,
Thanks f
This patch allows uboot scripts make choices about where to boot from based on
the active mmc boot partition. This allows having two copies of kernel,
filesystems etc, and choosing which to boot from based off the active
bootloader partition.
Signed-off-by: Reuben Dowle
---
cmd/mmc.c | 2
/Documentation/arm/booting.rst#n126
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.rst#n45
Signed-off-by: Reuben Dowle
---
common/spl/spl_fit.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl_fit.c b/common
> -Original Message-
> From: Marek Vasut
> Sent: Tuesday, 20 October 2020 10:59 am
> To: Reuben Dowle ; u-boot@lists.denx.de
> Cc: Tom Rini
> Subject: Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
>
> On 10/19/20 11:50 PM, Reuben D
> The problem is that the previous alignment was 4 byte, now it is 8 byte and
> that breaks all the other assumptions. So, this patch should be reverted to
> fix
> the platforms which used to work (or use ALIGN(...4), which is the same as
> reverting it really).
What assumptions? Any code that
2020 10:40 am
To: u-boot@lists.denx.de
Cc: Marek Vasut ; Reuben Dowle ; Tom Rini
Subject: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
This reverts commit eb39d8ba5f0d1468b01b89a2a464d18612d3ea76.
The commit breaks booting of fitImage by SPL, the system si
> The reverted change linked to some kernel documentation that requires 64-
> bit alignment. I agree with the alignment requirement.
>
> Im my opinion, there are two things that need to be done:
>
> First is to look at an ALIGNED address for the fdt. A summary inspection of
>
> > 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
am also interested to know where the 8 byte alignment requirement is
documented.
Reuben
> -Original Message-
> From: Tom Rini
> Sent: Tuesday, 25 August 2020 2:27 am
> To: Reuben Dowle
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] Fix data abort caused by mis
perhaps.
> -Original Message-
> From: Tom Rini
> Sent: Tuesday, 25 August 2020 8:40 am
> To: Reuben Dowle
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] Fix data abort caused by mis-aligning fit data in
>
> On Mon, Aug 24, 2020 at 08:05:24PM +, Reuben Dowl
> Two general comments. First, please use CONFIG_IS_ENABLED() to test for
> the new symbols so that we won't have any growth in SPL if we have one
> of these enabled in the main binary but NOT SPL.
It is not clear to me how I should be using CONFIG_IS_ENABLED(). I
have copied the pattern of
was a uboot FIT file. The total size varies depending on the
uboot device tree size, which does not always lead to correct alignment.
Signed-off-by: Reuben Dowle
---
common/spl/spl_fit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
This patch allows uboot scripts make choices about where to boot from based
on the active mmc boot partition. This allows having two copies of kernel,
filesystems etc, and choosing which to boot from based off of the active
bootloader partition.
Signed-off-by: Reuben Dowle
---
cmd/mmc.c
>
> Could you also update doc/usage/mmc.rst?
>
I have sent a v4 patch that also updates the documentation.
Hi Jaehoon,
>
> boot_ack / boot_partition / partition_access are optional variable, not
> mandatory.
> And it's confused that different variable is used with same command.
>
> I think that it's enough to use "mmc partconf ". Then it's showed which
> partition is used.
>
> If you have to apply
This patch allows uboot scripts make choices about where to boot from based
on the active mmc boot partition. This allows having two copies of kernel,
filesystems etc, and choosing which to boot from based off of the active
bootloader partition.
Signed-off-by: Reuben Dowle
---
cmd/mmc.c | 18
This patch allows uboot scripts make choices about where to boot from based
on the active mmc boot partition. This allows having two copies of kernel,
filesystems etc, and choosing which to boot from based off of the active
bootloader partition.
Signed-off-by: Reuben Dowle
---
cmd/mmc.c | 14
Hi Jaehoon,
> is mandatory, and [ ] is
> optional.
> If optional variable will be used, those variables can be mandatory, right?
>
> mmc partconf is displayed even without other variables.
>
> "mmc partconf [[varname] | [
> ]]" is correct usage for yours.
>
> It means varname or other
I submitted an almost identical patch. See
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
This patch eventually had to be reverted
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
because it was causing issues on some
25 matches
Mail list logo
