U-boot

U-boot

[Roman Kopytin]

Hello, dear U-boot team

I have question about your old feature: U-boot patch for adding of the public key to dtb file.
https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/

I can’t understand, can we work only with public key? Why do we need to have private key for adding step?
In documentation it is not very clear for me.

Thanks a lot.

Re: U-boot

[Michael Nazzareno Trimarchi]

Hi Román


On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin <Roman.Kopytin@kaspersky.com>
wrote:

> Hello, dear U-boot team
>
> I have question about your old feature: U-boot patch for adding of the
> public key to dtb file.
>
> https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/
>
> I can’t understand, can we work only with public key? Why do we need to
> have private key for adding step?
> In documentation it is not very clear for me.
>

You need to sign with private key and keep it secret and local and verify
it during booting with public key. Private key is not distributed with the
image

Michael


> Thanks a lot.
>
>
>

RE: U-boot

[Roman Kopytin]

Thanks, Michael.
Can we sign in the separate state on special server for example?
Looks like we can work with public key only in this step.

From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Sent: Friday, July 30, 2021 8:50 PM
To: Roman Kopytin <Roman.Kopytin@kaspersky.com>
Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org>
Subject: Re: U-boot

Caution: This is an external email. Be cautious while opening links or attachments.


Hi Román


On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin <Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote:
Hello, dear U-boot team

I have question about your old feature: U-boot patch for adding of the public key to dtb file.
https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/

I can’t understand, can we work only with public key? Why do we need to have private key for adding step?
In documentation it is not very clear for me.

You need to sign with private key and keep it secret and local and verify it during booting with public key. Private key is not distributed with the image

Michael


Thanks a lot.

Re: U-boot

[Thomas Perrot]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

Hi Roman,

On Sat, 2021-07-31 at 03:34 +0000, Roman Kopytin wrote:
> Thanks, Michael.
> Can we sign in the separate state on special server for example?

Yes, it possible, there is a step to build and another one to sign,
that can be separated.

For example, the following command, that build and sign the itb:
# build and sign
mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u-
boot.dtb -r ./foo.itb

Can be spitted in two:
# build
uboot-mkimage \
    -D "-I dts -O dtb -p 4096" \
    -f ./foo.its \
    ./foo.itb

# sign
uboot-mkimage \
    -D "-I dts -O dtb -p 4096" -F 
    -k ./keys \
    -K ./u-boot.dtb \
    -r \
    ./foo.itb

Then the u-boot*.dtb should contains the pubkey node(s) in the
signature node and it can be shared and concatenated to the U-Boot
binary:

make EXT_DTB="./u-boot.dtb"

> Looks like we can work with public key only in this step.

The dtb containing the public key(s) is useful to verify the signature
at the target boot, or with the tool fit_check_sign to perform an
offload checking, for example:

fit_check_sign -f ./foo.itb -k ./u-boot.dtb

Best regards,
Thomas Perrot

> 
> From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> Sent: Friday, July 30, 2021 8:50 PM
> To: Roman Kopytin <Roman.Kopytin@kaspersky.com>
> Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org>
> Subject: Re: U-boot
> 
> Caution: This is an external email. Be cautious while opening links or
> attachments.
> 
> 
> Hi Román
> 
> 
> On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < 
> Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote:
> Hello, dear U-boot team
> 
> I have question about your old feature: U-boot patch for adding of the
> public key to dtb file.
>  
> https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/
> 
> I can’t understand, can we work only with public key? Why do we need to
> have private key for adding step?
> In documentation it is not very clear for me.
> 
> You need to sign with private key and keep it secret and local and
> verify it during booting with public key. Private key is not
> distributed with the image
> 
> Michael
> 
> 
> Thanks a lot.
> 

-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

RE: U-boot

[Roman Kopytin]

Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side.

-----Original Message-----
From: Thomas Perrot <thomas.perrot@bootlin.com> 
Sent: Saturday, July 31, 2021 9:52 AM
To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org>
Subject: Re: U-boot

Hi Roman,

On Sat, 2021-07-31 at 03:34 +0000, Roman Kopytin wrote:
> Thanks, Michael.
> Can we sign in the separate state on special server for example?

Yes, it possible, there is a step to build and another one to sign, that can be separated.

For example, the following command, that build and sign the itb:
# build and sign
mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u- boot.dtb -r ./foo.itb

Can be spitted in two:
# build
uboot-mkimage \
    -D "-I dts -O dtb -p 4096" \
    -f ./foo.its \
    ./foo.itb

# sign
uboot-mkimage \
    -D "-I dts -O dtb -p 4096" -F 
    -k ./keys \
    -K ./u-boot.dtb \
    -r \
    ./foo.itb

Then the u-boot*.dtb should contains the pubkey node(s) in the signature node and it can be shared and concatenated to the U-Boot
binary:

make EXT_DTB="./u-boot.dtb"

> Looks like we can work with public key only in this step.

The dtb containing the public key(s) is useful to verify the signature at the target boot, or with the tool fit_check_sign to perform an offload checking, for example:

fit_check_sign -f ./foo.itb -k ./u-boot.dtb

Best regards,
Thomas Perrot

> 
> From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> Sent: Friday, July 30, 2021 8:50 PM
> To: Roman Kopytin <Roman.Kopytin@kaspersky.com>
> Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org>
> Subject: Re: U-boot
> 
> Caution: This is an external email. Be cautious while opening links or 
> attachments.
> 
> 
> Hi Román
> 
> 
> On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < 
> Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote:
> Hello, dear U-boot team
> 
> I have question about your old feature: U-boot patch for adding of the 
> public key to dtb file.
>  
> https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-g
> it-send-email-sjg%40chromium.org/
> 
> I can’t understand, can we work only with public key? Why do we need 
> to have private key for adding step?
> In documentation it is not very clear for me.
> 
> You need to sign with private key and keep it secret and local and 
> verify it during booting with public key. Private key is not 
> distributed with the image
> 
> Michael
> 
> 
> Thanks a lot.
> 

--
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Re: U-boot

[Simon Glass]

Hi Roman,

On Sat, 31 Jul 2021 at 02:26, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote:
>
> Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side.

(please try not to top-post on the mailing list)

Presumably this means that you know what the public key is, so one
option is to manually add it to the dtb, e.g. in a u-boot.dtsi file
for your board. You can see the format of it in the documentation, or
just copy what is there when you do the signing.

Another option would be to use 'fdtput' to add the various fields in
the dtb after building.


- Simon

>
> -----Original Message-----
> From: Thomas Perrot <thomas.perrot@bootlin.com>
> Sent: Saturday, July 31, 2021 9:52 AM
> To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org>
> Subject: Re: U-boot
>
> Hi Roman,
>
> On Sat, 2021-07-31 at 03:34 +0000, Roman Kopytin wrote:
> > Thanks, Michael.
> > Can we sign in the separate state on special server for example?
>
> Yes, it possible, there is a step to build and another one to sign, that can be separated.
>
> For example, the following command, that build and sign the itb:
> # build and sign
> mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u- boot.dtb -r ./foo.itb
>
> Can be spitted in two:
> # build
> uboot-mkimage \
>     -D "-I dts -O dtb -p 4096" \
>     -f ./foo.its \
>     ./foo.itb
>
> # sign
> uboot-mkimage \
>     -D "-I dts -O dtb -p 4096" -F
>     -k ./keys \
>     -K ./u-boot.dtb \
>     -r \
>     ./foo.itb
>
> Then the u-boot*.dtb should contains the pubkey node(s) in the signature node and it can be shared and concatenated to the U-Boot
> binary:
>
> make EXT_DTB="./u-boot.dtb"
>
> > Looks like we can work with public key only in this step.
>
> The dtb containing the public key(s) is useful to verify the signature at the target boot, or with the tool fit_check_sign to perform an offload checking, for example:
>
> fit_check_sign -f ./foo.itb -k ./u-boot.dtb
>
> Best regards,
> Thomas Perrot
>
> >
> > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> > Sent: Friday, July 30, 2021 8:50 PM
> > To: Roman Kopytin <Roman.Kopytin@kaspersky.com>
> > Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org>
> > Subject: Re: U-boot
> >
> > Caution: This is an external email. Be cautious while opening links or
> > attachments.
> >
> >
> > Hi Román
> >
> >
> > On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin <
> > Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote:
> > Hello, dear U-boot team
> >
> > I have question about your old feature: U-boot patch for adding of the
> > public key to dtb file.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-g
> > it-send-email-sjg%40chromium.org/
> >
> > I can’t understand, can we work only with public key? Why do we need
> > to have private key for adding step?
> > In documentation it is not very clear for me.
> >
> > You need to sign with private key and keep it secret and local and
> > verify it during booting with public key. Private key is not
> > distributed with the image
> >
> > Michael
> >
> >
> > Thanks a lot.
> >
>
> --
> Thomas Perrot, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
>

Re: U-boot

[Rasmus Villemoes]

On 31/07/2021 18.59, Simon Glass wrote:
> Hi Roman,
> 
> On Sat, 31 Jul 2021 at 02:26, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote:
>>
>> Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side.
> 
> (please try not to top-post on the mailing list)
> 
> Presumably this means that you know what the public key is, so one
> option is to manually add it to the dtb, e.g. in a u-boot.dtsi file
> for your board. You can see the format of it in the documentation, or
> just copy what is there when you do the signing.
> 

I sent
https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes@prevas.dk/
1.5 years ago. Roman, is it something like that you need? We've used
that patch/tool internally ever since.

> Another option would be to use 'fdtput' to add the various fields in
> the dtb after building.

Yes, but that, or the .dtsi approach, requires figuring just exactly
what those fields are supposed to be. And even if one could "reverse
engineer" that and implement the math separately in another tool, it's
much better to utilize the same code which "mkimage proper" would use,
since there's less risk of messing up endianness etc., and only one
place to fix bugs.

Rasmus

RE: U-boot

[Roman Kopytin]

Thanks a lot!
Yes, looks like using of the 'fdtput' is not very safety for me.
As I understood I need to use "fdt_add_pubkey" tool with CMD (example):
./ fdt_add_pubkey  -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> my_file.dtb

-r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage.


-----Original Message-----
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
Sent: Monday, August 2, 2021 12:00 PM
To: Simon Glass <sjg@chromium.org>; Roman Kopytin <Roman.Kopytin@kaspersky.com>
Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com>
Subject: Re: U-boot

Caution: This is an external email. Be cautious while opening links or attachments.



On 31/07/2021 18.59, Simon Glass wrote:
> Hi Roman,
>
> On Sat, 31 Jul 2021 at 02:26, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote:
>>
>> Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side.
>
> (please try not to top-post on the mailing list)
>
> Presumably this means that you know what the public key is, so one 
> option is to manually add it to the dtb, e.g. in a u-boot.dtsi file 
> for your board. You can see the format of it in the documentation, or 
> just copy what is there when you do the signing.
>

I sent
https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes@prevas.dk/
1.5 years ago. Roman, is it something like that you need? We've used that patch/tool internally ever since.

> Another option would be to use 'fdtput' to add the various fields in 
> the dtb after building.

Yes, but that, or the .dtsi approach, requires figuring just exactly what those fields are supposed to be. And even if one could "reverse engineer" that and implement the math separately in another tool, it's much better to utilize the same code which "mkimage proper" would use, since there's less risk of messing up endianness etc., and only one place to fix bugs.

Rasmus

Re: U-boot

[Rasmus Villemoes]

On 02/08/2021 11.25, Roman Kopytin wrote:
> Thanks a lot!
> Yes, looks like using of the 'fdtput' is not very safety for me.
> As I understood I need to use "fdt_add_pubkey" tool with CMD (example):
> ./ fdt_add_pubkey  -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> my_file.dtb
> 
> -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage.

Yes, that's very close to what our Yocto recipe currently does:

        for b in ${KERNEL_PUBLIC_KEYS} ; do
                fdt_add_pubkey -a 'sha1,rsa2048' -k
"${KERNEL_SIGNING_DIR}" -n "$b" \
                        -r conf $dtb
        done

I doubt that old patch applies nowadays, I've only forward-ported it to
2020.04 internally.

As to Simon's old question of whether it could be done in mkimage with a
new flag: I'd really prefer not to, mkimage is already an incoherent
collection of tools that do very different things with different flags.
Having a flag that says "create and sign this FIT image, and as a side
effect update $this dtb $overhere with the corresponding public key
mangled appropriately, oh, and btw, _only_ do that side effect" is a
non-starter.

Rasmus

RE: U-boot

[Roman Kopytin]

Yes, I don't see this tool in master branch.
May be I will take code and build this tool.

Do you have a plan for sharing it in repo?


-----Original Message-----
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
Sent: Monday, August 2, 2021 12:37 PM
To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org>
Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com>
Subject: Re: U-boot

Caution: This is an external email. Be cautious while opening links or attachments.



On 02/08/2021 11.25, Roman Kopytin wrote:
> Thanks a lot!
> Yes, looks like using of the 'fdtput' is not very safety for me.
> As I understood I need to use "fdt_add_pubkey" tool with CMD (example):
> ./ fdt_add_pubkey  -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> 
> my_file.dtb
>
> -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage.

Yes, that's very close to what our Yocto recipe currently does:

        for b in ${KERNEL_PUBLIC_KEYS} ; do
                fdt_add_pubkey -a 'sha1,rsa2048' -k "${KERNEL_SIGNING_DIR}" -n "$b" \
                        -r conf $dtb
        done

I doubt that old patch applies nowadays, I've only forward-ported it to
2020.04 internally.

As to Simon's old question of whether it could be done in mkimage with a new flag: I'd really prefer not to, mkimage is already an incoherent collection of tools that do very different things with different flags.
Having a flag that says "create and sign this FIT image, and as a side effect update $this dtb $overhere with the corresponding public key mangled appropriately, oh, and btw, _only_ do that side effect" is a non-starter.

Rasmus

Re: U-boot

[Rasmus Villemoes]

On 02/08/2021 11.55, Roman Kopytin wrote:
> Yes, I don't see this tool in master branch.
> May be I will take code and build this tool.
> 
> Do you have a plan for sharing it in repo?

Well, the repo for "sharing" this would/should be upstream U-Boot, and
if there's sufficient interest I'll rebase and resend - though I can't
promise any time frame, as there's a lot of other things on my plate. If
you have the time, feel free to take the code and submit it yourself.

Rasmus

RE: U-boot

[Roman Kopytin]

Thanks, I have good result with tool. Ok, I will check my tasks and will try to add this tool.

-----Original Message-----
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
Sent: Monday, August 2, 2021 2:09 PM
To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org>
Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com>
Subject: Re: U-boot

Caution: This is an external email. Be cautious while opening links or attachments.



On 02/08/2021 11.55, Roman Kopytin wrote:
> Yes, I don't see this tool in master branch.
> May be I will take code and build this tool.
>
> Do you have a plan for sharing it in repo?

Well, the repo for "sharing" this would/should be upstream U-Boot, and if there's sufficient interest I'll rebase and resend - though I can't promise any time frame, as there's a lot of other things on my plate. If you have the time, feel free to take the code and submit it yourself.

Rasmus

RE: U-boot

[Roman Kopytin]

Hi, dear U-boot team
Is it correct repo git://git.qemu.org/u-boot
?
We have it as our upstream.

-----Original Message-----
From: Roman Kopytin 
Sent: Monday, August 2, 2021 2:19 PM
To: 'Rasmus Villemoes' <rasmus.villemoes@prevas.dk>; Simon Glass <sjg@chromium.org>
Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com>
Subject: RE: U-boot

Thanks, I have good result with tool. Ok, I will check my tasks and will try to add this tool.

-----Original Message-----
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
Sent: Monday, August 2, 2021 2:09 PM
To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org>
Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com>
Subject: Re: U-boot

Caution: This is an external email. Be cautious while opening links or attachments.



On 02/08/2021 11.55, Roman Kopytin wrote:
> Yes, I don't see this tool in master branch.
> May be I will take code and build this tool.
>
> Do you have a plan for sharing it in repo?

Well, the repo for "sharing" this would/should be upstream U-Boot, and if there's sufficient interest I'll rebase and resend - though I can't promise any time frame, as there's a lot of other things on my plate. If you have the time, feel free to take the code and submit it yourself.

Rasmus

Re: U-boot

[Simon Glass]

Hi Rasmus,

On Mon, 2 Aug 2021 at 03:37, Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 02/08/2021 11.25, Roman Kopytin wrote:
> > Thanks a lot!
> > Yes, looks like using of the 'fdtput' is not very safety for me.
> > As I understood I need to use "fdt_add_pubkey" tool with CMD (example):
> > ./ fdt_add_pubkey  -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> my_file.dtb
> >
> > -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage.
>
> Yes, that's very close to what our Yocto recipe currently does:
>
>         for b in ${KERNEL_PUBLIC_KEYS} ; do
>                 fdt_add_pubkey -a 'sha1,rsa2048' -k
> "${KERNEL_SIGNING_DIR}" -n "$b" \
>                         -r conf $dtb
>         done
>
> I doubt that old patch applies nowadays, I've only forward-ported it to
> 2020.04 internally.
>
> As to Simon's old question of whether it could be done in mkimage with a
> new flag: I'd really prefer not to, mkimage is already an incoherent
> collection of tools that do very different things with different flags.
> Having a flag that says "create and sign this FIT image, and as a side
> effect update $this dtb $overhere with the corresponding public key
> mangled appropriately, oh, and btw, _only_ do that side effect" is a
> non-starter.

I missed that comment at the time...I think this tool is useful though.

The series is marked as deferred in patchwork, probably because the
thread died. How about reposting it?

Regards,
Simon

Re: U-boot

[Simon Glass]

Hi Roman,

see signature.txt :

- required: If present this indicates that the key must be verified for the
image / configuration to be considered valid. Only required keys are
normally verified by the FIT image booting algorithm. Valid values are
"image" to force verification of all images, and "conf" to force verification
of the selected configuration (which then relies on hashes in the images to
verify those).

Regards,
Simon


On Wed, 10 Nov 2021 at 04:20, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote:
>
> Hi, Rasmus and Simon
> I need more details about -r <conf|image> for fdt_add_pubkey.
> I need to add small help for tool, please provide details.
>
> -----Original Message-----
> From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> Sent: Monday, August 2, 2021 12:37 PM
> To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org>
> Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com>
> Subject: Re: U-boot
>
> Caution: This is an external email. Be cautious while opening links or attachments.
>
>
>
> On 02/08/2021 11.25, Roman Kopytin wrote:
> > Thanks a lot!
> > Yes, looks like using of the 'fdtput' is not very safety for me.
> > As I understood I need to use "fdt_add_pubkey" tool with CMD (example):
> > ./ fdt_add_pubkey  -a rsa2048 -k <keydir> -n <keyname> -r <conf|image>
> > my_file.dtb
> >
> > -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage.
>
> Yes, that's very close to what our Yocto recipe currently does:
>
>         for b in ${KERNEL_PUBLIC_KEYS} ; do
>                 fdt_add_pubkey -a 'sha1,rsa2048' -k "${KERNEL_SIGNING_DIR}" -n "$b" \
>                         -r conf $dtb
>         done
>
> I doubt that old patch applies nowadays, I've only forward-ported it to
> 2020.04 internally.
>
> As to Simon's old question of whether it could be done in mkimage with a new flag: I'd really prefer not to, mkimage is already an incoherent collection of tools that do very different things with different flags.
> Having a flag that says "create and sign this FIT image, and as a side effect update $this dtb $overhere with the corresponding public key mangled appropriately, oh, and btw, _only_ do that side effect" is a non-starter.
>
> Rasmus

U-Boot

[Shakhrukh Shakirov]

Hi guys,

I need consultation regarding U-BOOT, how to realize following on Raspberry pi 5:
We have 1 SD card which stores: U-BOOT, OS1, OS2, OS config
So UBOOT starts OS1 with OS config.
From OS1 I can upgrade OS2, and change boot orders (so it will run not OS1, instead will run OS2 with OS config).
From OS2 I can update firmware of OS1.
In case of failure of OS1 or OS2, it will run other OS version.
With who can I consult and what would be the rate?

Thanks  in advance.

Re: U-Boot

[Heinrich Schuchardt]

On 2/16/26 11:31, Shakhrukh Shakirov wrote:
> Hi guys,
> 
> I need consultation regarding U-BOOT, how to realize following on Raspberry pi 5:
> We have 1 SD card which stores: U-BOOT, OS1, OS2, OS config
> So UBOOT starts OS1 with OS config.
>  From OS1 I can upgrade OS2, and change boot orders (so it will run not OS1, instead will run OS2 with OS config).
>  From OS2 I can update firmware of OS1.
> In case of failure of OS1 or OS2, it will run other OS version.
> With who can I consult and what would be the rate?
> 
> Thanks  in advance.
> 

Hello Shakrush,

The Raspberry Pi has a firmware that supports A/B booting without 
needing U-Boot, see

https://www.raspberrypi.com/documentation/computers/config_txt.html#example-update-flow-for-ab-booting

E.g. Ubuntu 26.04 uses this when updating the Linux kernel.

If you don't have any specific requirement that needs U-Boot (like 
loading the kernel via HTTP), I would go for the Raspberry firmware 
solution.

Best regards

Heinrich

u-boot

[Dharshini V]

Good Afternoon,

      I want to learn U-Boot and create u-boot for Xilinx Zynq 7000 series. Are there any training courses or resources available? I’m particularly interested in hands-on projects to deepen my understanding. Any recommendations for tutorials or guides would be helpful too.

Regards,
Dharshini.V
________________________________
DISCLAIMER: This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Opinions, conclusions and other information in this transmission that do not relate to the official business of Quest Global and/or its subsidiaries, shall be understood as neither given nor endorsed by it. Any statements made herein that are tantamount to contractual obligations, promises, claims or commitments shall not be binding on the Company unless followed by written confirmation by an authorized signatory of the Company.
________________________________

U-Boot

[mcnernbm]

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

I have a question about U-Boot.  I have a board with no flash capability 
at all.  Will u-boot work on a xilinx board with no flash and only sdram? 
Can uboot be downloaded into sdram and used to boot linux?
Thanks
Brett

[-- Attachment #2: Type: text/html, Size: 361 bytes --]

Re: U-Boot

[Wolfgang Denk]

In message <OF3D06561E.1EB2655E-ON852570BB.00015870-852570BB.00016F3F@notes.udayton.edu> you wrote:
>
> I have a question about U-Boot.  I have a board with no flash capability 
> at all.  Will u-boot work on a xilinx board with no flash and only sdram? 
> Can uboot be downloaded into sdram and used to boot linux?
> Thanks
> Brett
> --=_alternative 00016F3D852570BB_=
> Content-Type: text/html; charset="US-ASCII"

One questions, three goof-ups.

1) This is the linuxppc-embedded list. U-Boot related  questions  are
   off topic here and should be posted to u-boot-users instead.

2) The answers to your questions are "yes" and "yes", but you  posted
   without reading the FAQ. See especially
   http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

3) Please don't post HTML to public mailing lists.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Today is the yesterday you worried about tomorrow.