Hi Fabio,

We have dfu_alt_info set. So that we can capsule update from UEFI. First, "setenv -e -nv -bs -rt -v OsIndications =0x04" And then we can "efidebug capsule update -v ${loadaddr}".

To make the capsule binary, we need to create a capsule1.itb with the following content: /dts-v1/;

/ { description = "Automatic U-Boot environment update"; #address-cells = <2>;

images { flash-bin { description = "U-Boot binary on SPI Flash"; data = /incbin/("flash.bin"); compression = "none"; type = "firmware"; arch = "arm64"; load = <0>; hash-1 { algo = "sha1"; }; }; u-boot-itb { description = "U-Boot binary"; data = /incbin/("u-boot.itb"); compression = "none"; type = "firmware"; arch = "arm64"; load = <0>; hash-1 { algo = "sha1"; }; }; }; };

And then "./tools/mkimage -f capsule1.its capsule1.itb" "./tools/mkeficapsule --fit capsule1.itb --index 1 capsule1.bin"

And we can tftp the capsule1.bin to ${loadaddr} and then use the capsule update.

Yours, Paul

On Fri, 2 Jul 2021 at 00:39, Fabio Estevam festevam@gmail.com wrote:

Hi Paul,

On Thu, Jul 1, 2021 at 12:45 PM Paul Liu paul.liu@linaro.org wrote:

...

Hi Fabio,

Yes. It is able to not provide the fip,bin. If you use bl31.bin as bl31.bin then fip.bin can be empty. If you use bl2.bin as bl31.bin then you have to have the fip.

This depends on how TF-A are being built. If you build TF-A without NEED_BL2=yes. Then you don't need the fip.bin. If you build TF-A with NEED_BL2=yes. Then FIP is needed. And you have to

use bl2.bin generated by TF-A and rename it to bl31.bin. I think maybe I can fix the README. If you can do that then that's perfect because my English is always not very good. So that means I sometimes need more review on my English sentences.

Thanks for the clarification.

I can work on creating a README file for this board after I manage to boot it.

What is the process of flashing the flash.bin and u-boot.itb binaries to the eMMC?

Do you use the uuu tool? If so, what is the uuu_script script that you use?

Thanks,

Fabio Estevam

Hi Fabio,

It might work. But why? I mean the imx8mm-evk has already switched to binman on the mainline. So we should do the same. If you can't get into U-boot prompt using binman I can give you more detailed information.

Yours, Paul

On Wed, 11 Aug 2021 at 07:13, Fabio Estevam festevam@gmail.com wrote:

Hi Paul,

Thanks for your response.

On Thu, Jul 1, 2021 at 6:38 PM Paul Liu paul.liu@linaro.org wrote:

...

Hi Fabio,

We have dfu_alt_info set. So that we can capsule update from UEFI. First, "setenv -e -nv -bs -rt -v OsIndications =0x04" And then we can "efidebug capsule update -v ${loadaddr}".

To make the capsule binary, we need to create a capsule1.itb with the

following content:

...

/dts-v1/;

/ { description = "Automatic U-Boot environment update"; #address-cells = <2>;

   images {
           flash-bin {
                   description = "U-Boot binary on SPI Flash";
                   data = /incbin/("flash.bin");
                   compression = "none";
                   type = "firmware";
                   arch = "arm64";
                   load = <0>;
                   hash-1 {
                           algo = "sha1";
                   };
           };
           u-boot-itb {
                   description = "U-Boot binary";
                   data = /incbin/("u-boot.itb");
                   compression = "none";
                   type = "firmware";
                    arch = "arm64";
                   load = <0>;
                   hash-1 {
                           algo = "sha1";
                   };
           };
   };

};

And then "./tools/mkimage -f capsule1.its capsule1.itb" "./tools/mkeficapsule --fit capsule1.itb --index 1 capsule1.bin"

And we can tftp the capsule1.bin to ${loadaddr} and then use the capsule

update.

In my case, I have the original U-Boot 2020.04 version from Compulab on the IoT Gateway board.

Would it be possible to run a patch like this https://pastebin.com/raw/Rq1Yv6ka

And then just load flash.bin via TFTP and flash it to offset 33K of the eMMC?

Would that work?

Thanks,

Fabio Estevam

Hi Paul,

On Tue, Aug 10, 2021 at 10:33 PM Fabio Estevam festevam@gmail.com wrote:

Hi Paul,

On Tue, Aug 10, 2021 at 10:06 PM Paul Liu paul.liu@linaro.org wrote:

...

Hi Fabio,

It might work. But why? I mean the imx8mm-evk has already switched to binman on the mainline. So we should do the same. If you can't get into U-boot prompt using binman I can give you more detailed information.

The reason I removed binman support was only for debugging purposes, as I don't plan to use fip.bin.

Even if I keep binman support and only remove fip.bin to prevent the build failure like this: https://pastebin.com/raw/FZ7D0rK0

I still cannot boot:

U-Boot SPL 2021.07-00001-g54086b3f1019-dirty (Aug 10 2021 - 18:39:22 -0300) DDRINFO: Cfg attempt: [ 1/6 ] DDRINFO(M): mr5-8 [ 0xff000010 ] DDRINFO(T): mr5-8 [ 0x5000010 ] resetting ...

U-Boot SPL 2021.07-00001-g54086b3f1019-dirty (Aug 10 2021 - 18:39:22 -0300) DDRINFO: Cfg attempt: [ 2/6 ] DDRINFO(M): mr5-8 [ 0xff000010 ] DDRINFO(T): mr5-8 [ 0x1061010 ] resetting ...

U-Boot SPL 2021.07-00001-g54086b3f1019-dirty (Aug 10 2021 - 18:39:22 -0300) DDRINFO: Cfg attempt: [ 3/6 ] DDRINFO(M): mr5-8 [ 0xff000010 ] DDRINFO(T): mr5-8 [ 0xff000010 ] Normal Boot WDT: Not starting Trying to boot from MMC2

Could you confirm whether U-Boot 2021.07 boots for you?

Any ideas, please?

Thanks